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ABSTR.ACT 


V 

The  rising  percentage  of  system  costs  attributed  to  software  development  and 
maintenance  have  resulted  in  the  research  by  indiistrv-  and  academia  into  v.  a>s  to 
improve  the  productivity  of  software  professionals  in  ill  phases  of  the  "icftware  life- 
cycle.  Computer  Aided  Software  Engineering  (C.ASE)  environments  are  one  ^ciuticn 
being  pursued.  This  thesis  attempts  to  coalesce,  from  various  elTorts  to  date,  some 
general  principles  for  such  environments  in  order  to  assist  decision  makers  v  ho  must 
procure  them.  This  work  is  in  support  of  the  Missile  Software  Branch,  Naval  W  eapon 
Center.  China  Lake,  Cali,^ornia  'MSB"),  and  their  investigation  of  C.ASE  ens ironment'- 
to  improve  productivity.  Problems  of  CASE  development  and  use  are  discussed  in  tins 
contc.'tt.  .A  general  problem  solving  approach  through  abstraction  of  resources  is 
proposed  v.'ith  a  focus  on  an  individual  programmer  productivity  subset  of  a  C.ASE 
environment.  |  f  e  jr  S  )  , 

1 
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I.  INTRODUCTION 


Since  its  infancy,  the  software  industr\'  has  worked  to  impro'-e  the  environment 
in  which  people  work  to  create  software.  In  general,  thes'  efforts  were  paced  by 
hardware  developments  and  by  the  way  programmers  thought  about  programming. 
The  development  of  assembly  and  then  higher  level  programming  languages  was  an 
environmental  improvement  (over  machine  language)  because  they  allowed 
programmers  to  think  in  m,ore  abstract,  logical  terms  about  the  problems  their 
pregram.s  were  solving.  System  operators  and  operating  systems  relieved  tiie 
programmer  from  the  burden  of  managing  hardware  resources.  The  move  from  offline 
batch  interaction  to  online  real  time  interaction  was  another  major  improvement  in  the 
environment  of  programmers.  .As  more  and  more  software  resources  to  improve  the 
programmers  environment  have  been  introduced,  the  hardware  designers  have  provided 
the  speed  and  computing  power  r.ecessan.'  to  support  all  of  these  features,  and  real 
work,  without  bringing  systems  to  their  knees. 

The  hardware  advances  resulting  from  VLSI  and  other  technologies  have  allowed 
the  proliferation  of  low  cost  computers  throughout  modern  society,  resulting  in  an 
explosion  in  the  demand  for  software.  The  drastic  improvements  already  being  made 
in  software  engineering  methods  have  not  kept  up  with  this  demand. 

For  the  past  decade  and  m.ore.  the  software  industn.'  has  expended  much  elTcrt 
on  tlw  issues  of  software  engineering  as  a  methodology  analogous  to  other  engineering 
fields,  and  to  the  development  of  automated  tools  and  environments  to  support  this 
ntothodclogy  and  enhance  the  productivity  of  software  developers  and  maintaincr';. 

This  thesis  attempts  to  coalesce,  from  various  software  development  env.ronmcnt 
elToits  to  date,  scm.e  general  principles  for  such  environments  to  aid  the  dcci'icn 
maicers  who  must  procure  them.  We  begin  by  discussing  the  snfr.-.are  t  ve ‘.i  <  ^./;c 
:he  so/iwar;  cngiritciing  prohiem  and  tlic  issue  of  environments.  Ve  then 
consider  a  particular  research  and  development  software  group.  Mis.'iic  So;':\w;re 
Branch.  Naval  Weapon  Center.  China  Lake.  Ca.  '.MSB),  their  mission,  their  need  for  a 
Compv-ter  .Aided  Software  Engineering  Environm.ent  iC.ASE).  and  some  of  tiie  I'-'-ue'. 
thev  ;l.^e  in  procuring  a  C.ASE 


S 


The  concept  of  an  integrated  CASE  has  developed  to  include  the  cradle  lo  gra.e 
life  cycle  of  software.  VVe  discuss  the  general  state  of  technology  of  >oit\vare 
development  tools  and  environments  to  date  and  some  of  their  problems.  W'c  discuss 
abstraction  of  environment  resources  and  standardization  of  interfaces  as  potential 
solutions  to  problems.  To  limit  the  scope  of  this  elTort  we  focus  on  one  of  the  better 
developed  and  understood  subsets  of  a  CASE  environment,  the  aspect  of  individual 
programmer  productivity  (IPP).  in  terms  of  abstract  resources  applicable  to  any  C.ASE. 
Future  areas  of  study  are  suggested.  Recommendations,  for  Missile  Software  Br.inch 
procurement  elforts.  are  discussed  in  terms  of  general  C.ASE  principles  in  tiie  IPP 
context. 


a 
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II.  BACKGROL  ND  OF  SOFTWARE  ENGINEERING  AND 

ENVIRONMENTS 


A.  THE  SOFTWARE  ENGINEERING  PROCESS 

Scfcware  engineering  has  been  dcfiaed  m  naany  ways.  Boehm  ( 1981,  p.  16 1  called 
It  "the  application  ol'  science  and  mathematics  by  which  the  capabilities  of  computer 
equipment  are  made  useful  to  man  via  computer  programs,  procedures,  and  associated 
documentation."  The  focus  of  such  definitions  is  that  software  engineering  is 


engineering  in  the  same  sense  as  the  traditional  engineering  fields. 

It  should  be  clear  that  wc  arc  not  talking  about  one  person  programming  for  liis 
sole  individual  use.  We  are  talking  about  the  case  where  more  than  one  person  is 
msolved  in  developing  and  or  using  the  software  products.  In  general  terms  there  are 
at  a  nunimum:  a  customer  (an  individual  or  organization! s)  who  want  something  uscfui 
done  by  a  computer),  a  developer  (an  individual  or  orgamzationis)  who  must  c.iginccr 
tiie  software  to  meet  the  customer's  need),  a  user  (who  may  or  m.ay  not  be  the  sarne  as 
the  customer)  and  a  maintaincr '  who  may  or  may  not  be  the  same  as  the  dc\ eloper  . 

,\n  applicable  definition  of  process  when  referring  to  the  sojiware 
pr'Hess  IS.  "...  a  series  of  actions  or  operations  ccnducing  to  an  endi  e-p. 
^c:i:;riucus  operation  or  treatment  esp.  in  manufacture  .  .  i  ll’el's:er  s.  1^^66.  p.  irs  . 
U'o  take  the  "end"  in  the  sci'tware  engineering  process  to  be  an  operational  '-ersion  cf 
a  '.o.'V.’.  ire  product  including  the  object  code  and  all  attendant  documciitaticii  •ix'tii 
■‘ii'.t cri.ai  .i:id  del;'. crable)  required  to  recreate  it. 

1  he  (.omanon  waterfall  rr.cdcl  of  the  software  life  cvcle.  figure  2. 1  iBoelin'.. 
p  ,•('',  aim  nunor  variations,  is  otten  used  to  capture  the  major  'top  Ic'. c!'  "■-criC'-  'f 
..c:;on>  or  cperarions"  in  the  software  engineering  process,  fins  trad. non  li  -.ic.v 
..ppcai  s  in  the  literature  as  far  back  as  a  1956  paper  written  by  Herbert  D  Bcmi.i.g;^ 
de'^r.bmc  work  on  t.he  S.\GL'  a.r  defense  s\siem  sci'tware  ( Benmneton.  I  (s',  "i  '-n,, 


The  IEEE  Nmt'n  International  Gont'erence  on  Software  fincineerine,  •  \l.i:v 


2  i98".  Montcrev.  (fahlbrnia.  I  S.\i  met  with  the  theme  ol  'Torm.fi/n.g  . 

.\ jton.-r.ii'ig  cite  Software  Procesv."  During  the  opening  Plenars  Se'^Mon.  I'r 
(  omimfec  ('a- :li  nnnan  Ro^'crt  Bai/er  stated  that  tnc  traditional  v  .;tcrfaf  ir.a.icl 
’  .c  v.ftaare  engineering  hfc  cr vie  ".s  dead".  Our  purpo'-e  liere  is  net  to  de"..;e  : 


c\c'.  ^so^^  ;s  bu'cu  rn  a  'relief  tiiat  tiie  uaterl'..!.  medei  nrnsme-  . 


known  terminology  and  common  framework  around  which  much  cf  ^olt'A.irc 
engineering  to  date  can  be  discussed.  We  believe  that  the  waterfall  mode!  represent'  a 
cop  level  view  of  the  software  engineering  process  when  the  process  is  vicu  ed  stati(.  j:!> 
Such  .1  static  view  is  often  attempted,  and  may  be  appropriate,  in  dealing  svuh  s\  stems 
wlicre  the  problem  and  solution  methods  are  well  known  and  defined. 

U'hen  faced  with  uncertainty  in  the  definition  of  the  problem  or  r".e:hc.Js  o; 
solution,  understanding  evoiscs  throughout  the  software  engineering  process  ar.u  a 
static  view  of  the  whole  lil’e  csc.e  is  inappropriate.  We  believe  that,  in  such  a  c.ise.  .t 
waterfall  model  is  still  useful,  but  not  as  the  top  level  of  the  process.  Instead,  m^jor 
portions  cf  it  e.’tist  at  a  lower  level  cf  a  process  which  may  be  categorized  as 
evolutionary-  prototyping.  In  other  words,  a  waterfall  model  applies  at  many  le\eis  of 
tlic  overall  software  engineering  life  cycle  process.  In  our  view  of  such  a  dsnanuc 
process,  a  v.aterfaii-iike  sequence  of  transformations  may  be  executed  repeatccis  'c 
"conduce"  progressisely  more  functional  versions  of  the  “end""  product.  Since  the 
water'ail  model  imposes  no  temporal  constraints  on  its  phases,  an  initial  vers. on  m.av 
be  py'u'oiyped  rapidls  by  manipulating  not  only  the  functionality  of  the  prototype 
'.ersion.  but  the  complexity  and  detail  of  some  phases  of  that  \ersion  s  I,fe  i.>le  .\ 
result  ca.n  oe  top  down  design,  with  a  combination  of  top  down  and  bettem  up 
impiementation.  of  a  fairuly  of  evolutionary  versions.  Each  new  version  is  csoiwd 
extension  of  the  collectise  analysts,  design,  impiementation  and  testing,  etc.,  ol  'Oiv.e 
prior  \ersion.  This  approach  can  deal  dynanucally  with  problem  solution  u:'n.erni.r.f. 
eariv  m  a  prciect  deseiopment  lile  cycle,  as  well  as  with  continued  esolutic,-.  cl"  liie 
pro;ec;  over  time  and  in  the  context  of  technological  adsancc.  Lch.man  1-iss, 
discusses,  in  detail,  the  dynamics  of  software  evolution  with  respect  to  his  ne.v  far.;. li.ir 
S.  P  .ird  E  program  classes.  He  also  discusses  the  process  of  iterative  transjo-m  iron 
through  waterfall  like  phases  from  topmost  (i.e..  requirements!  specitictfior  tc  I'.r.al 
..mpicr.entation  i  in  this  case  a  prototype  or  subsequent  versions).  Leiiiv.an  '  iterat.-.e 
transformation  is  based  on  a  single  canonical  design  step  whereb'  the  solV.vare  ergircci 
^reatr. eiv  chooses  a  formal  iewer  level  linguistic  sxstem  .n  which  to  n'.fJn  h.c  rigiie' 
Ij'.cI  rtcdel  with  which  he  begins  each  step.  Ecrmalism  is  intended  to  'Up;':rt  ,i 
mapping  from  the  higher  le\e!  model  to  the  subsequent  lower  level  model  !a...l.t.it.ng 
v;alcui..blc  ' s  empirical)  verification,  backtracking  and  change  propcgatic.t  .m'lM’ios 
i..h  lead  t:  iteration  of  the  design  step  and  support  evolution.  Sue;;  fcrm.di'-ni  >  no; 
m  .-omn'.cn  practical  use  in  industry  today.  Such  a  process  is  intended  to  help  w.  id 


throu'ing  out  large  portions  of  prior  development  work  and  having  to  start  over  ironi 
scratch 

Speak.ng  at  the  IEEE  Ninth  International  Conference  on  Software  Eng.ncer;:'g. 
rieibert  Bennington  commented  that  the  successtu!  SAGE  development  elTcris  -.'.ere 
:io:  \.ri\ on’  by  ihe  waterfad-Iike  model  illustrated  in  his  Idft-'  paper.  Bat,  th^t  a 
proto p.ng  proco'-v  based  on  these  activities,  was  employed  to  deal  d'. nanuoailv  ■vitii 
MO  iincorta.ntv  .nvoo.ed  .n  tne  prc;oi.:s  ambitions  and  possible  solutions  S)  th.CiO 
ML^^^  are  i-r  I'rcm  nev.  Fhc’.  have  been  studied  and  gained  prerrunence  in  the  cc:.-e\: 

1  •'as:  sui.i.esses  and  failures  Given  these  views  of  the  software  engineering  pro^esv. 
we  ^an  discuss  brieilv  cur  view  of  the  software  engineering  protilem 


THE  SOFTvVARE  engineering  PROBLEM 

I  n.e  s  'r.-.e.rc  pc  or  smvis  to  use  a  popular  cliche,  has  n'..ini. 

.n  pror'lems  includ.r.g  quant. qualitv,  maintenance  and  management 

1  Quality 

Software  sa^ntv  is  a  lundam.en'.al  issue  Many  products  simply  den  t  Ja 
.ner  '.vant'  dire  causes  tor  tins  eeneraliv  reduce  to  the  inherent  dillk .-.nc' 
anon,  vcrn'.c.mor.  and  testing 

a.  i  aiidaiion 

Wii.daiion  IS  the  proces>  of  detemumne  the  fitness  of  a  software  r' 


s  operation.a.  nii's.on  The  developer  interacts  with  the  custcm.er.  r.  the  i 
.  :;w.i:e  engineering  process,  to  trinsfiie  the  customers  need  into  a  rccj*.,re 
:’.^>n.ior.  \’  iiidat:on  .it  th.s  vt.iee  tries  to  deternune  that  tlie  ngiit  pred.-wt 

.eered.  The  customers  ucscription.  of  -.vm;  the  product  nv..st  do,  .s  nf.e- 
Cv.'C  becnu.se  i:  is  e.xpressed  in  a  scrr.anticaiiv  iniprec.se  natural  tar.-uace 
'ill,  'ATthin  his  own  organi/ation.  the  developer  translates  the  rcuiiuei' 
pu  M  into  a  requirements  specif.catior.  Tins  has  tradit.on.ulv  been  the  f.t'" 
ircm  natural  language  toward  a  mere  precise  representation  \'ajda'..  n  , 


:  .e  developers  representation  s^i-eir.c  Next,  the  de'-e.cpcr  trans'.itcs  tlve 
..er.ients  'pccdicution  .r.to  design  spec.fications  Design  'pecuic’s 
renients  w.li  '•'c  met  Tiie  lugii  levc.  reo^uircmcn’ '  spcc-tkation  of 
renfv  Mnt.un  il.  the  uct.ul  rc>,;',.ircM  'o  r*taNe  explicit  design  dcuis  '-' 


i..e't;.,  ns  .:..se.  c 


inscicU'  etlo't  wvuld  be  made  to  revaiida'e  the  re — re: 


i...ut,on  vMtn  t.te  cus’omer  'O  tn,.:  'ne  recuuentents  'pc>.;t:c..iMn 


questions.  Often  this  does  not  happen.  Sometimes  it  is  not  even  clear  to  the  designer 
that  his  decision  cannot  be  validated  from  the  requirements.  .Additionally,  design 
representation  ;s  generally  so  far  removed  from  the  customer  s  view  and  understanding 
that  an  inherently  -.morecise  reverse  translation  is  required  in  order  to  get  any  .'cedback 
ironi  the  customer  at  this  point.  .After  implementation,  validation  must  deterrrunc  if 
the  r.ght  product  was  actually  built.  .As  we  ll  discuss  later,  this  last  phase,  testing,  is  an 
inherently  imprecise  process. 

b.  \  erification 

Verification  assumes  that  the  requirements  specification  is  valid  and  tries  to 
ensure  that  the  product  is  built  correctly.  The  developer  must  translate  design 
specifications  into  an  implementation  in  object  code  for  the  target  machine.  Since 
design  specifications  are  a  more  precise  representation,  this  translation  is  m.uch  more 
di.'ect.  In  fact,  systems  ha\e  been  implemented  in  which  specifications  are 
automatically  translated  from  design  languages  to  source  code  languages  which  are 
then  translated  into  object  code  by  compilers.  However,  these  programs  themselves 
car.  r. :t  as  yet  be  proven  correct,  so  empirical  verification  is  essential  to  injure  the 
inter.:  af  tlie  design  is  met  by  the  object  code.  For  two  decades,  considerable  eifart  has 
been  devoted  to  proving  the  correctness  of  programs  1  verification).  However,  testing 
continues  to  be  tiie  best  available  tool  for  verification  and  validation. 

c.  Te'itina 

It  IS  generaiiy  accepted  that  exhaustive  testing  (instrumented  execut.on  cl'  a 
program,  in  its  precise  operational  environment,  over  every  possible  combination  of 
•  i.putsi  IS  net  I'easible  lor  other  tiian  t.'iviai  programs.  It  is  also  accepted  thit  nothing 
'’.'.or:  of  cxhaastr.c  testing  will  infer  program  correctness.  .As  Dijkstra  «aid,  "program 
toeing  can  'oe  used  to  show  the  presence  of  bugs,  but  never  their  absence"  Dahl. 

I ^"2.  p  M  So.  the  prim.ary  cbjective  of  testing  becomes  demonstration  ol  the 
prcgrai.'.s  cperationai  readiness.  Individual  tests  must  be  mapped  I'rcm  tlie  dc'^ign 
Npecilications  for  verification  and  from  requirements  specifications  I'cr  validation.  S.n^e 
e\':i.ius;.-,e  testing  cannot  realistically  be  performed,  a  reasonable  sublet  of  ah  pcss.bic 
tests  must  be  chosen,  ^Mth  knowledge  of  tiie  design  and  code,  ibv  not  smirK  treating 
mcdt.les  and  programs  as  "black  boxes"'  tests  can  be  chosen  for  boundr.  ccndo.icns, 
legal  ai'.vi  illegal  inputs,  volume,  etc.  and  logical  assumptions  can  be  made  about 
^cntintiiiv  0.  tuntt.on  between  boundary  conditions.  Fiver,  il  the  program  execute"  the 
tests  W  ithout  errors,  and  the  logic  .s  ur.f.awcu.  operational  readiness  ;s  only  site.’  n  ii. 


the  specific  environment  tested.  Was  some  unforsecn  combination  of  inputs  onutteJ.’ 
Is  the  targe:  machine  and  its  firmware  and  system  software  identical  to  the  test 
machine'’ 

2.  Quantity 

Proiiferation  of  computers  throughout  modern  society  has  caused  an  explosion 
in  Jem.uid  for  software.  This  demand  is  a  double  edged  sword.  The  more  '.cff.sare 
there  IS.  the  more  software  there  is  to  be  maintained.  A  li.xed  number  ol"  software 
engineers,  with  fixed  productivity,  will  eventually  reach  a  point  where  all  of  their  elTort 
IS  consumed  by  maintenance.  No  new  software  can  be  developed  until  some  software  in 
ma.nteiur.ce  is  retired. 

^^'h^le  the  number  of  software  engineers  is  not  fixed,  several  industry  studies 
conclude  that  the  number  is  increasing  toe  slowly  to  keep  pace  with  increasing 
software  demands.  To  complicate  m.atters.  the  lifespan  of  existing  soltware  often 
exceeds  expectations.  This  is  particularly  true  in  the  L'nited  States  Department  of 
Defense  'DoDi  where  cap.tal  investment  in  nulitarizcd  hardware,  logistics  'lys-enw. 
training  of  technicians  and  operators,  etc.  ail  add  up  to  practical  and  political  inertia  to 
keep  a  working  sy<item  in  place  lanJ  :n  maintenance!  long  after  technolcgy  ^j'.'.es  ;t 
by  Im.prosing  the  productivity  of  software  engineers  appears  not  only  desirab.c.  but 
essential,  to  stemi  the  quantity  problem. 

a.  Reust: 

I  he  reuse  issue  is  actually  a  component  of  the  overall  issue  of  impros mg 
prcoiictivity  ol' software  engineers.  It  is  mentioned  separately  here  because  it  has  long 
been  tiiought  to  be  the  key  to  making  an  order  ol' magnitude  improvment  in  voltwire 
prud^’..t;or.  tapabiluy.  Since  the  earliest  days  software  engineers  have  redesigned  -nd 
rei.t'.plen'.cnted  things  which  had  been  built  before.  The  problems  of  reuse  v.eu 
known  .md  go  far  beyond  any  "not  invented  here"  egomania.  Reusable  >.ode  l.-ranes 
uiucc od  Nonie  eariv  success  for  discrete  I'uncticns  I'.iko  mathematical  formui.isi  It  was 


that  higher  order  languages  would  make  source  code  reuse  a  reality  for 
cmpl.cateJ  functions  and  program*;.  However,  a  general  lack  o!'  d.si-.pl 


w  : '..'lung  and  adhering  to  language  ‘;tandards  resulted 


et'  and  generally  inccnsistant  ur.plem.er.tations  of  compilers  ibr  vary. mg  in.; 
vl.ieitino  portabil.tv  of  '.uch  cude.  Additionallv.  at  the  larger  'cepe  o: 


s.\.iiipie\  .u..^..ons  .;nd  p*oce...ares. 


code  IS  too  detailed  u.e..  data  types,  u.it,; 


Tucture*;.  etc.!  !or  easv  reuse. 


.\'  a  rc'ult.  it  iS  cenerailv  the  ahsm.'wtien. 


domaia  specific  model),  and  not  the  concrete  implementation,  that  is  reutilized. 
(Standish.  1984,  p.  495)  In  genci  il.  even  the  reuse  of  the  abstraction  has  been  in.farmal 
at  best.  Documentation  of  requirements  and  design  specifications  generally  lacks 
standards  outside  a  particular  organization  (and  sometimes  within).  The  nhy  of 
particular  design  and  implementation  choices  is  often  unclear  in  documentation.  Tlie 
level  of  efi'ert  required  to  understand  what  an  existing  design  is  doing  and  what,  if 
anything,  must  be  done  to  adapt  it  to  a  new  application  or  new  eimronmcnt.  is  often 
seen  as  more  dilficult  than  starting  fresh.  So.  reuse  of  the  abstraction,  without 
methods  and  tools  to  reduce  the  understanding  overhead,  is  usually  informal. 
Individuals  use  their  own  prior  work  (things  they  understand  and  retain  in  their 
personal  toolbox i,  but  they  reject  organized  library  resources  as  too  hard  to  use.  This 
situation  is  changing  as  such  methods  and  tools  supporting  reuse  become  more 
available,  but  formal  reuse  is  still  absent  in  many  organizations. 
d.  ProJuctivity 

In  classical  terms  productivity  can  be  defined  as  units  of  product  delivered 
divided  by  cost.  Herein  lies  one  of  many  problems  associated  with  measuring  the 
productivity  o!' sottware  developers.  There  are  no  basic  units  of  software.  However, 
various  measures  have  been  developed  and  attempts  to  instrum.ent  and  study 
prcductisity  have  been  made.  In  general,  we  believe  productivity  in  software 
engineering  activity  has  been  worse  than  it  is  now.  We  believe  that  various  efforts  to 
i.mprove  the  sofiware  engineering  m.ethodology  and  environment  lia'.e  improved 
productivity  to  its  current  level.  .And.  uc  believe  further  improvements  are  posable. 
We  den  t  believe  precise  measurments  of  productivity  are  possible. 

Such  measu.'-ements  industrc'  wide  are  complicated  by  the  lack  of 
.meaningful  .measurement  standards  and  the  proprietary  nature  of  statistics.  Something 
as  seemungly  simple  as  lines  of  code  per  programmer  per  day  cannot  be  compared 
unless  one  defines  precisely  what  a  line  of  code  is.  Is  it  assembly  code  or  a  fov.rth 
gencrat.cn  language?  Is  their  more  than  one  statement  per  line?  Bevond  tins  ,s  the 
.s',.e  of  program  complexity.  H.ghly  modularized  code  is  likely  to  !n.'.e  mere  lines 
.i...n  unstructured  monolithic  un.mcdulanzed  code.  Yet  a  poor  design  can  yield  'U't  .iS 
many  cr  micre  lines  of  ir.oduianzed  code  as  a  good  design.  Which  represents  mere 
pro  Juctivityi' 

The  most  believable  claims  .‘cr  measuring  software  engineering  productivity. . 
and  productiv.ty  increases,  com.e  frem  studies  ithin  individual  organizations.  .At  le.ist 
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they  measure  activity  in  a  relatively  consistant  environment  (source  system  hardware 
and  software,  source  language,  methodology,  etc.),  with  consistant  measurem.ent  units 
(what  IS  a  line  of  code?)  and  with  a  relatively  consistant  group  of  individuals  over  the 
course  of  the  study.  With  such  a  semblance  of  a  controlled  environment,  the  impact  ol" 
introducing  new  tools  or  methods  becomes  more  measurable.  One  consistant  source  of 
such  reports,  for  a  number  of  years,  has  been  Boehm  at  TRW.  .'Boehm,  1981  and  198.' i 
One  can  argue  that  the  result  of  such  studies  can  be  generalized  for  other 
organizations.  One  cannot  argue  that  such  a  generalization  offers  any  precision.  But. 
It  IS  evidence  to  offset  the  risk  in  a  decision  to  invest  in  similar  tools  and  methods  for 
productivity  improvement. 

3.  Maintenance 

Software  maintenance  is  commonly  defined  as  any  work  on  a  software  s\  stem 
after  operational  release.  It  is  often  subdivided  into  m.aintcnance  to  correct  errors 
(corrective  maintenance)  or  maintenance  to  improve  or  modify  capability  (sometimes 
called  perfective  maintenance).  In  either  case,  maintenance  involves  changing  the 
program.  Without  a  complete  understanding  of  how  the  program  works  and  why  the 
designers  chose  to  make  it  work  that  way.  a  maintainer  can  often  introduce  totally 
unexpected  errors.  Such  a  change  can  invalidate  all  prior  testing.  Mainta;ncr<  arc 
often  not  the  original  developers,  and  they  must  rely  on  the  documentation  of  the 
development  process  for  the  understanding  required  to  change  a  software  svstem. 
They  need  to  be  able  to  repeat  testing  and  compa.''e  results  to  original  tests  in  order  to 
deternune  the  operational  readiness  of  the  new  (maintained)  version,  Tlicy  must 
conduct  and  document  new  tests  to  demonstrate  readiness  of  new  capabilities.  Much 
of  dcs  elcpment  and  maintenance  documentation  for  existing  software  has  been 
inadequate  to  support  efficient  maintenance  efforts.  Often,  much  of  the  dcveiopmc.nt 
clfor:  must  be  repeated  to  do  maintenance  well.  In  reality,  driven  by  pressure  to  moo: 
operational  deadlines,  much  maintenance  results  from  efforts  closer  to  trial  and  error 
\ccdlcvs  to  say.  documentation  of  such  efforts,  if  any,  is  seldom  beneficial  to  follow :i 
m.ai.ntcnance. 

d.  Management 

Management  problems  have  been  a  major  driving  factor  towards  sofn.vjrc 
engineering  methodologies  and  tools  Problems  such  as;  late  deliver.'.  O'.er  budge;. 
ur.rcli..ble  product,  failure  of  product  to  meet  'pecifications  and  product  dilficul;  and 
expcn'i. e  to  maintain;  are  cenunon.  They  are  attributable  in  par;  ;c  ;:;c  uviaii;;.. 
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quantity  and  maintenance  issues  already  discussed.  The  familiar  phrase,  "Yea  can  t 
manage  uhat  you  can't  measure.”,  sums  up  part  of  management's  woes.  .Another 
nay  or  contributor  to  management  problems  is  the  chaos  inflicted  on  static  plans  when 
tlio  well  defined  problem  or  solution  unc.xpectedly  evolves  into  something  else.  Such 
■attempts  to  manage,  based  on  measurement  of  the  .vrong  things,  are  further 
complicated  by  the  phase  in  the  life  cycle  when  the  change  is  discovered.  Changes  or 
errors  involving  the  requirements  and  design,  which  are  not  discovered  until  late  in  the 
development  process,  are  often  much  more  expensive  to  correct.  They  can  often  result 
in  discarding  much  of  the  work  already  done. 

In  the  last  decade  software  engineering  methodologies,  tools  and  en'.ironments 
hate  exploded  on  the  market  offering  a.nd  delivering  partial  solutions  to  the  ceftuare 
problem,  '^^'ork  and  controversy  surrounding  development  environments  continues. 

C.  DEVELOPMENT  ENVIRON.MENT  A  SOLLTION 

.A  software  development  environment  is.  m  general  terms,  the  domain  m  winch 
the  software  system  is  developed.  From  the  view  of  software  engineers  this  domain 
eor.MSts  of  methods,  tools  (computer  hardware  and  software)  and  other  sertuare 
engineers  (the  managers,  analysts,  designers,  programmers,  etc.  who  make  up  the 
engineering  team).  In  other  words,  all  of  the  resources  necessary  to  engineer  softw  are, 

1 .  Structured  .Methodology 

Since  the  early  19'0  s.  st.'ucturec  methods  for  managing  and  developing 
software  h.ave  been  written  about,  taught  and  implemented.  The  structured  metl•.cd^ 
support  the  major  activities  cf  the  waterfall  model  (Figure  2.1). 

By  structured  methods  we  mean  a  collection  of  procedures  and  concepts  :o 
increase  the  productivity  and  effectiveness  of  the  software  engineering  organ.-x  tion. 
elements  of  tlte  structured  methods  include: 

•  'Structured  analysis,  guidelines  and  graphical  tools  that  allou  replacing  the 
traditional  representations  of  the  requirements  specification  with  one  tlvi:  car, 
be  more  easily  understood  by  the  customer; 

•  top-down  design  and  implementation; 

•  structured  design,  guidelines  and  methods  to  help  the  designer  distingu.'-n. 
between  good  and  bad  designs; 

•  structured  progra.Ttrrung.  ccniposuion  of  program  logic  from  sequence.  :f-:licn- 
else  and  dc-while  constructs  wuh  little  or  no  use  of  the  go-to. 

.Associated  with  these  methods  are  aids  to  implementation  such  as: 
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•  program  librarians,  to  relieve  programmers  of  clerical  tasks  and  manage  version 
control  and  archival; 

•  structured  walkthroughs,  peer  group  review  of  design  and  implementations  to 
assist  in  error  reduction  and  schedule  pacing  between  formal  inspections 

(\’curdon.  19S6.  pp.  2-3). 

Controversy  about  the  value  of  these  and  other  methods  often  centers  around 
hew  much  they  improve  productivity  and  effectiveness.  As  indicated  earlier,  ho^v  much 
IS  a  dilficult  thing  to  measure  and  compare  with  any  precision.  'I’ourdcn  sa\s  "In 
genera!  .  .  .  they  double  the  productivity  of  the  average  programmer,  increase  the 
reliability  of  his  code  by  an  order  of  magnitude,  and  decrease  the  ditficulty  oi' 
maintenance  by  a  factor  of  two  to  ten.”  (Yourdon,  19S6.  p.  3)  Well  just  say  that 
common  sense  indicates  these  methods  should  improve  productivity  and  elTcctiveness, 
and  our  general  sense  of  reports  from  industry,  regarding  such  methods,  is  that  they  do 
work  with  substantial  benefit. 

One  of  the  serious  problems  encountered  try  ing  to  use  these  m.ethods  is  that  a 
tremendous  amount  of  cross  referencing  of  data  and  data  structures  from  one  phase  of 
the  life  cy,.le  to  another  is  required.  Also,  many  tasks  are  cyclic  in  nature  and  require  a 
lot  cf  repetitive  activity.  For  instance,  validation  of  a  data  How  diagram  representi.nc  a 
revjuiremer.t  specification  nught  require  reiterating  the  diagram  several  times  with 
nunor  ciianges  as  the  customer  and  developer  narrow  down  exactly  what  the  customer 
wants.  Each  named  piece  of  data  on  the  diagram  is  a  unique  entity  recc.'ded  in  a  d.r.a 
d.c'-icnary.  Each  new  change  to  the  diagram  must  be  checked  against  the  data 
d,i.tionart  to  ensure  all  items  are  uniquely  recorded.  Sucli  repetitive  or  pure!', 
meciianical  tasks  tend  to  be  error  prone  and  slow  when  done  by  humans.  Titov  are 
e\i.eilent  candidates  .''or  automation  using  a  computer.  (MacLennan.  l'^S3.  p. 

2.  .Automation 

There  are  generally  three  fr-ms  of  automation  supporting  settware 
engineering. 

u.  Tools 

Tools  are  programs  that  perform  a  single  type  of  .‘unct.on.  .\  crnipiier. 
that  generates  object  code  for  a  target  machine  from  source  code  in  a  specific-  language. 
i>  a  tool,  as  are  assemblers,  linkers,  editors,  graphic  tool  boxes,  spread  sheet  pregramv. 
etc.. 
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b.  Programming  Support  Environments 

Programming  support  environments  are  collections  of  tools  to  provide 
support  for  programming  (normally  considered  the  implementation  phase  of  the  life 
cycle I.  They  generally  only  directly  support  programmers.  They  may  be  a  cooperative, 
interoperable  set  of  tools  (what  we  will  call  a  toolset)  specifically  designed  to  work 
together  with  a  common  user  interface  and  common  data  exchange  formats.  Or.  they 
may  be  a  set  of  disjoint  tools  which  are  separately  e.xecuted,  each  with  its  own  user 
interface,  each  performing  its  task  on  its  own  internal  data  structures,  generaih  with  a 
sequential  file  of  characters  as  the  only  e.xternal  data  interface  with  each  other. 

c.  Computer  Aided  Software  Engineering  (CASE)  Environments 

CASE  environments  are  a  relatively  new  concept.  They  are  an  extension  of 
programming  support  environments  to  the  entire  software  engineering  life  cycle.  They 
are  intended  to  provide  support  to  the  entire  engineering  team  (i.e.,  managers,  analysts, 
designers,  programmers,  maintainers.  etc.)  for  overall  product  develop.ment. 

3.  The  Environment  Jungle 

^^'e  have  been  automating  aspects  of  the  environments  in  which  we  engineer 
sofiware  for  a  long  time.  ,At  first  there  were  simply  collections  of  whatever  software 
tools  were  available  for  the  hardware  and  languages  we  wanted  to  use.  in  general, 
partly  due  to  the  large  number  of  languages  being  developed,  only  the  most  basic  tools 
were  available  (assemblers,  linkers,  loaders,  compilers)  to  support  production  of  object 
code.  Tliese  environments  were  based  in  batch  processing  techniques.  As  hardware 
advances  produced  teletype  terminals  for  on-line  real-time  processing,  environments 
cave  the  illusion  'in  the  user  interface)  of  being  interactive  with  the  computer.  This 
was  still  sequential  batch  processing  (for  that  user),  only  the  batches  were  much 
smaller  and  turnaround  time  much  faster.  Video  terminals  evolved  directly  from 
teletype  terminals,  still  processing  lines  of  characters.  The  natural  data  structure  to 
evolve  for  external  interfaces  in  such  environments  were  files  of  sequential  characters. 
These  are  still  the  most  common  "standard"  data  exchange  format  ir.du>try  wide.  Smee 
there  are  more  than  one  ''standard''  character  code  je.g.,  .-XSCIl  and  EBCD(''.  filter 
programs  are  employ  ed  for  portability  of  files. 

.As  hardware  provided  inc.xpensive  speed  and  raw  computing  power,  assisted 
by  operating  systems  offering  virtual  memory  support,  a  few  languages  began 
conm-.andm.g  a  large  market  share.  .As  software  engineers  came  to  grips  with  t!ie 
softw.'.re  problem,  more  complex  interoperable  toolsets  appeared.  These  interoperab.e 
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tools  often  rely  on  conimon  data  structures  (other  than  simple  sequential  character 
files)  representing  objects  which  can  be  viewed  and  manipulated  by  various  functions 
within  each  tool.  These  objects  are  normally  stored  in  a  database  accessible  by  all  of 
the  interoperable  tools.  The  database  objects  are  generally  only  meaningful  in  the 
context  of  their  tool  or  tool  set  which  often  must  eventually  produce  a  sequential 
character  file  for  manipulation  by  tools  not  integrated  with  the  set.  Tl^e  advent  of  bit 
mapped  graphic  objects  has  added  further  complexity  to  portability  of  data  among 
tods.  Due  to  storage  overhead,  and  the  complexity  of  handling  bit  images  instead  of 
the  objects  they  represent,  bit  mapped  graphic  objects  arc  generally  compacted  into 
unique,  complex,  proprietary  storage  code  which  constitutes  a  recording  of  the 
sequence  of  resource  ^tool)  calls  used  to  construct  the  object.  These  recordings  are 
replayed  and  edited  in  order  to  reconstruct  or  manipulate  the  objects.  The  storage 
form.at  of  such  objects  is  therefore  meaningless  outside  the  context  of  the  environment 
required  to  replay  it. 

a.  Integrated  vs.  Disjoint  Environments 

We  use  the  term  integrated  to  describe  environments  with  the  following 

features: 

•  all  resources  conform  to  a  consistant  user  interface; 

•  all  resources  are  as  highly  interoperable  as  possible; 

•  objects  and  their  interrelationships  are  in  a  persistent  common  data  format; 
which  IS  meaningful  to  all  environment  resources; 

We  use  the  term  disjoin:  to  describe  environments  which  lack  integration: 

•  inconsistent  user  interface  among  resources  requiring  user  to  shift  modes  when 
moving  from  one  resource  to  another. 

•  ir.compatable  data  formats  among  resources 

b.  Environment  Development  Efforts 

The  software  crisis  and  technological  advances  /hardware,  operating 
systems,  languages,  user  interfaces,  databases,  etc.)  have  resulted  in  a  bocnunc  new 
market  in  environments.  We  easily  collected  a  full  file  drawer  of  documentation  in  th.c 
I'crm  of  books,  papers,  technical  reviews,  promotional  materials,  ,ind  conference 
proceedings  describing  myriad  environments  under  research,  or  in  production  or 
operation.  What  is  generally  most,  common  about  these  encironments  is  that  they  have 
50  '.ery  liiiie  in  common. 

( 1 )  General  State  of  Technology.  Developing  a  C.ASE  environment  is  itsoif 
a  scitware  engineering  probie.m  of  mam-moth  proportions.  No  standard  requiremcms 
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for  a  CASE  environment  have  been  adopted.  Since  the  software  engineering  prcce^^ 
itself  is  less  than  mature  or  stable,  top  down  specification  and  design  of  an 
environment  to  model  it  has  been  deficient.  For  the  most  part  a  bottom  up  approacli 
i'.as  prevailed.  While  many  CASE  labels  have  been  hung  on  projects,  at  best  it  is 
l:miteJ  integrated  toolsets  that  are  being  made.  The  CASE  customer  who  can  define 
his  particular  software  engineering  process  is  unlikely  to  find  a  toolset  which  is  a 
complete  CASE  environment  for  his  process.  Since  data  portability  between 
independent  tools  and  toolsets  is  generally  limited  to  sequential  character  f;lc«. 
assembling  a  complete  CASE  environment  from  off-the  shelf  products  can  at  best  >  eld 
a  disjoint  environment.  The  majority  of  what  arc  being  called  CASE  environments 
today  include; 

•  graphic  tools  supporting  various  structured  analysis  and  design  methods; 

•  program  design  language  (PDL)  tools  supporting  prototyping  through 
executable  specifications; 

•  programming  suppon  environments  supporting  specific  language 
implementations,  debugging,  documentation,  version  control,  and  archival; 

•  project  management  systems  supporting  a  variety  of  management 
methodologies  and  economic  models; 

•  office  automation  toolsets: 

•  hardware  and  software  supporting  multiple  view  window  interlaces  and 
multitasking. 

.A  prevailing  point  of  view  seems  to  be  that  it  is  unlikely  that  any  single  organ;7at:on 
couid,  or  should,  define  canonical  requirements  for  some  C.ASE  environment  and  then 
implement  all  of  the  integrated  resources  to  instantiate  it.  * 


‘This  may  not  do  justice  to  a  few  large  software  developers  who  have  irU'Csted  :r. 
long  term  top  down  development  of  environments  for  their  own  use  bused  on  their  own 
software  engineering  process  and  methods  of  operation.  However  ib.ese  s>wten;s  are 
cither  generally  not  available  off  the  shelf,  or  represent  an  e.vorbitant  inve'tntent,  and 
ccniplete  integration  within  them  is  dubious.  A  possible  exception  .  the  .\da 

Dc\e!opment  System  from  Rational  (.Mountain  View.  California),  has  been  dc'.clcpcd 
for  the  market  place  and  is  touted  in  the  literature  to  epitomize  ".  .  .  the 
integrated  C.ASE  environmient."  (Suydam.  p.  i.S)  However,  most  would  cla"i;> 
the  RloUO  dedicated  hardvs'are  architecture  and  software  as  an  excrhitan:  in'. cstmci.t. 
.Also,  we  siiouid  note  that  European  C.ASE  environment  elTorts  .seem  more  ad'>anv.ed 
than  our  o'wn  domestic  endeavors.  IST.AR.  from  Imperial  Software  Teciinol :gy 
I  London.  Engkmdi.  is  an  example.  FST.AR  s  top  down  design  proiide.s  for  a  !le\;;':e. 
open  and  extensible  environment. 


It  is  generally  agreed  that  integration  of  tools  toolsets  ' resource' »  .s 
desirable  within  an  environment  for: 

•  coherence,  whereby  all  the  tools  behave  in  a  uniform  and  consistant  way  le  g  .  a 
coirunon  user  interface  style); 

•  control,  whereby  tools  behave  in  a  disciplined  way  (eg.,  not  .dio'vinc 
unintegrated  tods  to  bypass  and  subvert  a  configuration  management  tool  ': 

•  sharing,  whereby  tools  work  together  by  sharing  data  idata  is  strut' ured 
independently  of  the  tools  which  create  and  use  it) 

(Hall.  p.  289).  There  is  a  basic  conf.ict  between  the  desire  for  integration  ar.u  the 
desire  and  need  (economic  and  CNoiutionary)  for  environments  to  accept  tools  t'roin 
various  soUi'ces.  V.'e  feel  the  most  promising  of  the  current  approaches  to  resolsing 
this  con.'lict  is  to  build  around  a  kernel  structure  of  resources  whiCh  provide  serswes  to 
the  tools  for  accessing  and  manipulating  objects  in  a  standardized  entironrr.ent 
database.  Once  the  interfaces  to  these  kernel  resources  are  defined,  tool  develcpcr' 
who  adhere  to  the  interfaces  will  develop  integratable  tools.  Two  such  elTorts  currentlc 
underway  are  the  Portable  Common  Tool  Environment  iPCTE)  which  is  the  b.i'e  for  a 
number  of  European  environment  and  tool  projects  (including  IST.XR.  sec  1  -.gurc  2  2 
■  Honderscn,  19S~.  p.  59))  and  the  Common  Apsei.Ada  Programming  Su-'port 
En'.iror.ment)  Interlace  Set  <C.\IS)  sponsored  by  the  DoD. 

(2)  L'n:ted  States  Department  of  Defense  iDoD)  lnitiati.es.  Ear!'.  :n  ti.o 
DoD  comm.cn  higii-order  language  project  which  spawned  .Ada.  developers  rCvCgr.i.’oJ 
ti'.at  the  language  alone  would  be  insuiTicient  to  combat  the  problems  as'cci.-wd 
DoD  soi'tw..re  projects.  DoD  sponsored  de'-ciopment  of  lequircm.cnts.  dci'imi.c  'l.c 
.\da  Piogramnung  Support  Environment  l.APSEi.  with  the  stated  objective  " 
support  the  development  and  maintenance  of  .Ada  applications  so.Tware  thrcucl.ou:  .'.n 
ul'e  c;. cle.  with  particular  emphasis  on  software  for  embedded  com.putcr  apr:;..i:.  ■:>  ' 

'•  Stoaenii'a.  1980,  p.  1)  Fundamental  concepts  of  tiic  .APSE  included: 

•  host  target  environment,  where  the  .APSE  is  hosted  on  a  development  n..iJ..;ne 
whiie  the  target  machine  of  the  software,  to  he  developed  ut.li/mc  tlw  ^i'^l  . 
.may  be  a  difierent  machine;  * 

•  program  database,  to  inciuuc  ail  project  information  ic  g,  scu.we  a.nJ  .n: 
code,  documentation,  specilicattons.  etc.); 

•  extensibility,  with  all  tools  written  in  .Ada. 


*In  embedded  systems  the  target  hardware  may  be  so  limited  in  re'ouruj'  'occd. 
memcr.,  etc.)  that  it  cannot  pr.actically  support  the  development  environment 
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The  original  Sioneman  representation  of  the  APSE  is  illustrated  in  Figure  2.3  /Booch. 
19ST.  p.  409 ^  The  host  machine  resources  are  provided  through  the  Kerne!  .APSE 
(KAPSE;  -.vhich  provides  the  iOgical  to  physical  mapping.  The  .Mmimai  .APSE 
iMAPSE)  contains  some  nrummal  toolset  for  program  development,  and  the  .APSE 
overall  represents  a  l:fe  cycle  environment. 

3\'h;Ie  carh  Sronemati  de'.elopers  may  have  thought  in  terms  ol  a  single 
c'ganizat.on  developing  an  .APSE  or  MAPSE  under  DoD  sponsorship,  this  .  pprc.isli 
juickis  ran  into  the  integration  versus  independent  developers  ccnCict  mentioned 
earlier.  ^  Ccmr.'.ercial  developers  are  competitively  pushing  the  edge  of  lechnolo.;  m 
programming  support  and  (EASE  environm.ent  resources.  Any  standardized  irceeriteu 
tooEet  from  a  single  deselcper  faces  sti.T  competition  in  fields  (e.g.,  editors,  dehugger'. 
User  interi.tces.  etc.  i  where  few  widely  accepted  standards  exist  and  sescral  pctenti-i 
defacto  standards  mught  emerge.  To  encourage  the  competitive  advance  ct 
environment  technology  in  a  direction  supporting  integrated  environments,  DcD 
sponsored  the  de’.elopment  of  the  (fc.munon  .APSE  Interface  Set  (CAIS). 


Tl'.e  C.AIS  presides  interlaces  for  data  storage  and  retrieval,  data  transmussicn  to 
and  Horn,  external  ueMces.  and  activation  of  programs  and  control  cf  tiieir 
execution.  In  order  to  ashieve  unitornut;-  in  the  interfaces,  a  single  model  is  used 
to  vcr.'istentlv  describe  general  data  storage,  devices  and  executing  programs  .  .  . 
referred  :c  as  the  node  mcdel.  (Miliuiry  SiandiVii  Comment  APSE  Inu'Chcc  Sc: 

.  C  itS  .  WS\  p  U  ' 

The  deveiopment  oi'  ('.AIS  has  been  a  lengthy  and  methodical  process  cf  bounded 
'cepe  I ‘te  verMcn  of  tne  specification  s  hedulcd  for  release  in  the  Spring  of  F'S*  .s 
.n'-er, -ed  to  support  some  transportability  interfaces  often  required  by  cemmen 
are  dev eicpmer.t  tools,  including: 

•  the  node  model: 

•  processes,  (.over.ng  program  invocation  and  control; 

•  .nput  output,  covering  t'.ie  and  devic-e  1  ()  and  interprocess  comununicaticn. 

•  m..;t;es.  ii^t  .;pc.  .UiOn-  :  .tr  ntampui  ition  of  parameters  and  attribute  '.aiuc's, 
b  tme  (  .MS  issues  und  Jcd'.'.m.s  deferred  :cr  later  versions  of  the  C.MS  include: 


'  l  ie  .Armv  Navx  .Acia  Language  S'. stem  '.ALSi  was  such  a  venture  from  aiiich 
ti.e  .Arm',  hu'  now  ■.Mthd.'uv.n  support.  1  ;ie  \avv  .has  continued  with  .AI.S-N  '.vxtn  tiie 
s-'Cc.fic  purpose  cf  d.rcct.v  supporting  sonte  mamr  unique  Navx  embeddesi 
urci.;' -.'cf.ues.  It  has  been  untnip^ted  tiK.t  sucii  'upport  wfi  not  be  spontanesmis  ;:  o:n 
'.’.e  priv.ite  seder  slue  to  the  extren.e.'  imuteu  -.erticui  .market. 
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•  coiiHguration  managernent.  CAIS  supports  resources  for  configuratici'. 
management  but  no  speciJk  methodology; 

•  devices,  suppons  scroll,  page  and  form  terminals  and  magnetic  tape  drncs 
lotl'.er  devices  and  possibly  ether  ANSI  or  ISO  interfaces  <e  g.,  ISO  DIS  ”'^-12 
Graphical  Kernel  System  (GKSil  are  under  consideration); 

•  inter-tool  interfaces,  are  not  defined; 

•  mtcrcpcrabiiity.  only  a  primative  tc\t-or;cnted  file  transfer  capability  is  preuded 
between  a  C.AIS  implementation  and  its  host.  C.AIS  does  not  define  cvtcrnai 
data  formats  for  transfer  between  environments  or  between  a  host  and  target; 

•  archiving,  a  decision  on  the  form  that  archiving  interfaces  should  take  has  been 
deterred 

t  ’./i..;.:. .  ShhiJ::rii  Common  APSE  Interface  Set  {CAIS>.  19S5.  pp.  1-2). 

The  Software  Technology  for  .Adaptable  Reliable  Systems  tST.ARSi 
progra.m  established  by  the  DoD  in  late  19S3  included  the  ST.ARS  Software 
f-nginecring  Environment  iST.ARS-SEEi  task.  The  early  objectives  of  ST.ARS-SEf. 
were  to  specify  the  requirements  for  a  complete  life  cycle  environment  w-hich  u  as  fuliv 
iir.egrated  and  intc-operable.  multilingual,  utilized  state  of  the  art  technologv  and  -.vas 
.'.sea  designed  to  evclve  with  technology.  Early  ST.ARS  leadership  felt  that  the  DoD 
Itself  was  best  capable  of  analysis  and  definition  of  requirem.ents  for  such  .in 
environment.  .A  joint  services  team  composed  of  uniformed  and  DoD  civilian  soif.vare 
prci'cssionai<.  augmented  by  DoD  contractors,  analyzed  the  software  engineer  nc 
proce'N.  rcviuirements  for  the  ST.ARS-SEE.  and  the  state  of  technology,  Th>  rc'ul'ed 
;r.  eener.it;;-.  ol' a  five  volume  collection  of  thirty-five  preliminary  reports,  bv  1 --vi'. 
prej'.r.mon  for  defining  the  ST.ARS-SEE  software  architecture  iNav  ai  \;r 
Development  ('enter.  lvS6.  p  llyieafi  Changes  in  project  management  resnJted, 
es'enn.fil;. .  in  disbanding  the  ST.ARS-SEE  task  eiEort  witlnn  DoD  activities  and  'hm.r.c 
emj'i.i'.s  to  encouragement  and  support  of  private  sector  software  engmeerme 
env.rcr.n.ent  deve.opment  efrorts. 


In  addition  to  such  high  ievei  DcD  environment  mm.it.ves  as 
.\?^i  C.AIS  and  ST.\RS.  several  lower  level  efi'orts  e\:st.  DcD  field  activities  c;'.o..ccd 
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.'•are  engineering  alrcadv  have  an  investment  in  thc;r  own  ar, 
.mer.ts  which  have  evolved  bottom  up  'With  the  evolution  oi 
e  'Cvhnoiocyi  as  t..ev  have  done  their  jobs  over  the  years  They 
•  e..;lu:;cn  from  hatch  oriented  and  "interactive"  time 
ime  mini  complexes,  to  nct’.vorkcd  "personal"  nucrocomputers 
to  centra!  computme  rescurwes  Individaal  initiatives  to 
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environments  u-ith  relatively  inexpensive  “personal"  computers  and  ofT-the-shclf 
software  engineenng  tools  in  such  a  bottom  up  fashion  are  often  seen  as  both  blessing 
and  curse.  Blessing  for  their  contribution  to  improving  an  often  otherwise  extremely 
unproductive  working  environment,  and  curse  because  of  the  lack  of  intcrcperab;ia> . 
transportability,  consistancy.  etc.  which  they  represent.  *  DoD  Ada  implementation 
policy  (essentially  that  .Ada  is  the  only  authorized  programming  language  for  new 
embedded  systems  and  existing  systems  entering  major  revision)  has  been  cr.c  point  of 
focus  for  many  of  these  independent  elTorts  in  DoD  as  well  as  for  the  too!  and 
environment  developers. 


■‘Not  all  of  these  elTorts  arc  so  limited.  Some  are  large  and  well  organized  and 
funded  leg,.  the  Interactive  .Ada  Workstation  being  developed  under  contract  b> 
General  Clectric  for  the  .Avionics  Lab.  .A^^^.AL  .A.A.AF-2.  \\  P.AFB.  OIF.  and  ti  e 
Sol'tware  Life  Cycle  Support  Environment  (SLCSE)  being  developed  by  Genera! 
RcNcar^h  Corporation  under  sponsorship  of  the  L.S.  .Air  Force  Rcme  .\'.r 
Development  Center.  G.AFB,  N.'i'.i. 
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III.  CASE  DEVELOPME.NT  ISSUES  FOR  MISSILE  SOFTWARE 
BRANCH  (MSB),  CHINA  LAKE 


A.  MSB  BACKGROUND 

MSB  is  a  small  software  research  and  development  group.  They  are  a  branch  of 
the  Weapons  Development  Division,  Michelson  Laboratory,  Naval  Weapons  Center. 
China  La.ke.  California.  Software  engineers  in  the  group  are  domain  specialists  in 
onboard,  embedded  missile  software.  Prior  to  current  efforts  to  use  Ada.  '.inuallc  all 
of  their  work  involved  assembly  language  programs  for  unique  processors  with 
e.vtremely  limited  resources  (e.g,,  speed,  memory)  in  onboard,  mission  critical,  real-time, 
embedded  missile  systems.  Working  around  constraints  like  limited  memory  often 
requires  methods  (e.g..  unstructured  design)  which  subsequent!}  make  the  software 
extrcrr.ely  difficult  to  understand  and  maintain.  Reuse  of  such  hardware  specific  and 
unstructured  software  is  virtually  impossible.  Knowledge  of  the  weapon  domain  'a 
major  factor  itself:  is  often  the  only  reusable  resource  in  this  software  engineering 
process.  Hardwa.'-c  advances  with  the  potential  to  improve  the  resource  i  speed, 
memory,  etc.)  availability  of  potential  target  processors,  and  the  increasing  a\a.labli:;^ 
of  .Ada  compilers  for  target  processors.  ha\e  opened  the  door  for  MSB  to  exploit  ,\da  s 
inherent  support  for  structured  methods,  object  oriented  software  engineering  and  code 
pc.'tabiiity.  ' 

1  Mission 

Tile  basic  mission  of  .MSB  is  to  establish  and  maintain  a  Nacy  m-house 
capability  for  detcieping  state  of  the  art  missile  software.  .As  with  any  ro'-earch 
oriented  organization,  they  are  considered  a  resource  for  exploring  new  technoiogies 
winch  would  likely  remain  unexplored  in  the  profit  oriented  private  sector.  .As  a 
de'.ciopment  resource  they  m.ay  be  tasked  to  perform  some  or  ail  of  the  deceiopmen:  of 
softw..re  for  specific  missile  projects. 


•'Onboaru  embedded  software  operate^  m  a  unique  environment.  Size.  \vc:ght. 
power,  and  iieat  dissipation  cor.tinue  to  be  a  maje.-  concern,  and  even  ;cda\  liie 
scenario  may  not  apply.  EiTiciency  of  object  code  generated  bv  ;.iree: 
nuwh.nc  .\da  ^omphers  .s  aiso  o;'m..;;or  concern,  i. Myers.  DX',  pp.  “l-~2> 


2.  Problem 


Hardware  advances  (e.g..  VLSI)  have  proliferated  embedded  processors  into 
weapons  systems  projects  at  an  ever  increasing  rate.  The  impact  of  new  technoiogies 
on  the  operational  environment  of  the  weapons  (e.g.,  operational  deception.  eiec:ron;c 
warfare,  etc.)  demands  increasing  capabilities  for  mission  lulfillment.  New  technologies 
make  now  mission  capabilities  possible  and  or  essential.  As  a  result,  mission  i.r;tical. 
embedded  ststem  software  demand  (both  upgrade  of  e.visting  systems  and  new  s> stems 
development)  is  increasing  rapidly. 

Current  federal  policy  on  personnel  funding  elTectively  limits  any  increase  in 
.\IS3  personnel  resources  in  the  foreseeable  future.  Projects  rejected  (due  to 
insu.Ticient  capacity)  by  MSB  must  either  be  done  somewhere  else  (generally  private 
sector  contracts)  or  be  abandoned  or  postponed.  For  many  projects,  especially 
research,  the  ntissile  software  domain  e.xpertisc  of  .MSB  makes  them  the  best  equipped 
for  the  job.  Other  considerations,  such  as  security  of  operational  environment 
intelligence  and  hardware  advances,  can  make  in-house  research  and  development 
easier,  more  desirable  and  less  e.xpensive.  Our  purpose  here  is  not  to  attempt  to 
quantify  capacity  shortfall  at  .MSB.  or  its  cost  in  terms  of  private  sector  contracts  or 
unc.xplored  avenues  of  research.  But.  to  report  MSB’s  own  assessment  that  thev  are 
unable  to  keep  pace  with  demands  for  their  services. 

}.  Organization 

The  largest  organizational  subgroup  within  MSB  is  known  as  the  Software 
Technology  (ST)  group.  This  group,  currently  seven  software  engineers,  is  eng  iged  m 
various  projects  often  involving  ordy  one  or  two  people  per  project.  These  projects  are 
primartiy  research  oriented  (e.g..  rapid  prototyping  for  feasibiLty  demonstration!,  fhe 
cus:o>ner  sponsoring  such  projects  is  generally  the  project  manager  (not  part  of  MSB' 
for  the  particular  weapon  system  involved.  .Also,  independent  research  of  a  less  .y.  %ic>n 
specific  nature  (e.g.,  developing  and  benchmarking  .Ada  library  packages)  mav  he 
sponsored  by  the  branch,  department  or  some  other  activity.  Besides  the  ST  group,  a 
team  of  three  software  engineers  and  a  program  librarian  are  currently  engaged  ;n  a 
development  project  for  the  Sidewinder  missile.  There  are  three  software  engineer'  in 
the  Sparrow  missile  development  group.  There  is  a  Software  .Acquisition  Contracting 
Manager  group,  of  two,  who  are  dedicated  to  configuration  and  documentation 
management  for  the  branch.  Finally,  there  are  a  Branch  Head  and  a  secretary  bunging 
the  total  to  IS  personnel.  Development  teams  arc  formed  from  ST  group  pci'onnel 


assets,  and  return  to  the  ST  group  when  development  projects  end.  This  is  a  general 
description  of  the  MSB  organization  and  the  degree  of  flexibility  in  their  sol'tware 
engineering  process  required  to  meet  their  conamittments. 

4.  Current  Environment 

MSB  has  been  actively  improving  the  environment  within  which  they  work. 
Management  tailors  the  software  engineering  process  to  the  task,  at  hand.  Research 
projects  may  proceed  employing  structured  methods  and  top  down  design  for  rapid 
prototyping  without  pushing  the  entire  bow  wave  of  static  sequential  life  cycle 
constraints  required  (e.g.,  by  DoD  Standard  216')  when  a  project  enters  development. 
MSB  employs  structured  methodologies  espoused  by  bourdon  and  others.  MSB  is 
actively  engaged  in  research  to  demonstrate  .Ada  feasibility  for  missile  software.  This 
work  includes  performance  analysis  of  object  code  generated  for  potential  "olf  the 
shelf  target  processors.  They  are  developing  e.xpertise  in  object  oriented  design  with 
.Ada.  They  are  actively  researching  missile  software  domain  Ada  library  packages  and 
working  towards  reuse  of  design  and  code.  They  have  sponsored  development  of  an 
.Ada  code  analysis  metric  (Halstead  metric)  tool.  AJaMeasure,  (Fairbanks,  19’'“)  at  the 
Naval  Postgraduate  School  (NPS).  They  have  encouraged  other  NPS  ellbrts  ^ 
including  this  one.  which  focus  on  aspects  ofC.ASE  resources  and  development. 

To  the  extent  possible  with  available  funding.  MSB  has  upgraded  the 
hardware  and  software  of  their  host  development  system.  The  result  to  date  is  a 
uisjoint  environment  of  personal  nucrocomputer  workstations  with  local  area  network 
terminal  access  to  their  own  super-microcomputer  and  the  rentral  site  procc'^ors.  The 
MSB  microV.AX  II  runs  the  UNIX  operating  system  and  hosts  various  .Ada  compilers 
and  their  run  time  support  tools  (e.g..  debuggers).  Similar  resources  are  asaiLibie  on 
the  central  site  VAX.  The  personal  computer  wcrkstat.ons  cer.eraily  have 
individualized  collections  of  disjoint  tools  for  word  processing,  text  editing,  scheduling, 
'preadsheets.  grapiiic  drawing,  etc.. 


"L  nder  development  concurrently  with  this  work,  these  elforts  will  aho  result  in 
June  i9S"  th.eses.  ^^’hilc  titles  are  not  yet  firm,  the  works  arc  idcntiiled  by  Mib;cct  and 
author: 

•  .kn  .Ada  Ternunal  Interface  Package,  by  .Anthony  Kcough; 

•  Improved  .AJaMeasure  >  Henry  Ki.'ur  metric),  by  Paul  Hcrzig; 

•  Interactive  Grapiiics  in  a  C.XSF  environment  L  ser  Interface,  by  Gregg  Singer. 
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Recognizing  not  only  a  need,  but  an  obligation,  to  remain  a  viable  research 
and  development  resource,  by  remaining  competitive  in  terms  of  development  cost, 
productivity,  and  availability,  MSB  is  actively  investigating  CASE  environments 

5.  CASE  a  Desired  Solution 

In  the  Fall  of  1986.  MSB  began  to  actively  explore  CASE  solutions  to 
improve  productivity,  reduce  development  costs  and  improve  product  quality.  Thc:r 
high  level  requirements  included  automated  resources  supporting  the  following: 

•  C.ASE  environment  database  containing  code,  documentation,  specifications, 
requirements,  transformations,  design  histories,  project  summaries  and  cost 
projections  integrated  with  graphic  design  tools; 

•  librar.'.  supporting  reusability  of  source  code,  documentation,  tests  and  test 
data  and  object  code; 

•  documentation  generation,  supporting  their  research  prototype  process  and  the 
development  process  (DoD  Standard  2167  and  other  requirements); 

•  graphical  analysis  and  design.  supporting  Yourdon  structured 
analysis  structured  design  methodologies  and  .Ada  object  oriented  design; 

•  programming  support  including  style  guidelines,  static  and  d>namjc  an.ii>sis  and 
source  and  object  code  generation; 

•  oflice  automation,  supporting  project  management. 

In  addition,  they  identified  hardware  resource  constraints  including  support  for; 

•  networked  software  library  (database); 

•  .modern  graphics  oriented  methodologies  and  tools; 

•  team  approach  to  software  development. 

They  refined  these  hardware  constraints  further  to: 

•  n'.ultitasking.  supporting  parallel  simultaneous  interaction  with  environment 
resources; 

•  mega-pixel  graphics  resolution,  supporting  multiple  virtual  terminals  lor  parallel 
simultaneous  interaction  with  concurrent  tasks; 

•  mega-mstructions  per  second,  supporting  resource-intensisc  features  cl'  the 
system; 

•  mega-bytes  of  mam  ntemory.  supporting  resource-intensive  features  ot'  t';e 
system. 

(Missile  .Software  Branch.  1986.  pp.  6-S) 


B.  CASE  ENVIRONMENT  PROCUREMENT  ISSUES 


Withm  DoD.  procurement  of  any  large,  expensive,  complex  system  of  hardware 
and  sol'tware  (like  a  C.ASE  environment)  is  governed  by  policies  and  standards  which 
require  such  things  as  demonstration  of  economic  feasibility  and  documentation  of  the 
development  life  cycle  in  a  systematic  way  for  management  as  the  procure.ment 
progresses  le.g.,  DoD  Standard  21  o'  requirements).  Our  purpose  here  is  not  to  study 
tlie  process,  but  to  discuss  some  general  issues  which  would  arise  durir.g  such  a 
procurement.  .A  fundamental  issue  is  a  consideration  of  make  versus  buy.  By  make  we 
mean  to  make  or  have  made  (e.g..  under  contract)  a  system  which  is  designed  topdown 
for  the  unique  organization  and  software  engineering  processes  of  MSB.  By  buy  we 
mean  a  sytem  composed  of  existing  (off-the-shelO  products  which  are  purchased  to 
assemble  a  C.ASE  environment.  We  will  discuss  briefly  two  fundamental  aspect^  of  the 
buy  option.  In  the  first  case  one  buys  a  collection  of  tools  or  toolsets  from  a  variety  of 
sources,  choosing  each  for  the  particular  functional  resource  it  provides.  Because  of 
the  general  current  state  of  the  marketplace  in  tools  (ie;  lack  of  consistent  user 
interfaces,  lack  of  interoperabihty.  etc.)  the  best  result  of  this  approach  is  a  disjoint 
environment  asse.mbled  in  a  bottom  up  fashion.  We  call  this  a  short  term  appoach.  In 
the  other  case,  one  buys  a  complete  environment  (in  todays  marketplace  there  are  few 
choices)  which  has  been  designed  top  down  as  an  integrated  environment.  We  call  this 
a  long  term  approach. 

1  Short  Term  Off-the-shelf  Buy  Approach 

a.  Advantages 

il)  h'vncdiaie  Results.  Compared  to  an  environment  as  a  whole,  a  tool 
With.  Imuted  functions  is  relatively  inexpensive.  This  will  often  allow  fund.i'.g  Irom 
Ic'.ver  levels  witliin  a  bureaucracy  with  less  justification  and  shorter  prccurcment 
delays.  The  tool  can  be  in  the  working  environment  much  sooner. 

(2;  Ease  of  Extensibility  us  User  Experience  and  Technnl,->g-,  Ev'we 
Requirenients.  The  relatively  smiall  investment  in  any  partcular  to.Dl  in  the 
eif.  ircnmient.  allows  easier  justification  and  funding  to  enhance  the  environment  rv 
.tdJing  a  tool  which  fulfills  new  requirements  better  than  existing  tools,  or  add>  toM;i\ 
nc'.v  functions. 

■' ' )  Pick  Best  of  .4va:!ahie  T''>ols.  .As  discussed  previously  with  regard  to 
the  diicmima  of  integration  versus  a  variety  of  sources,  this  approach  encourage'  .iclC" 
to  the  best  technolcsv  available  now  or  in  tlie  future. 


b.  Disadvantages 

The  advantages  listed  above  lead  directly  to  some  major  disadvantages. 

(1)  Short  Term  Solutions  Create  Long  Term  Problems  {e.g.,  Creeping 
Evolution  of  the  Environment).  Within  a  software  engineering  environment,  the  issue  at 
hand  IS  production  of  a  software  product.  The  product  is  more  than  just  the  object 
code.  Change  (maintenance  in  the  traditional  view,  or  evolution  in  the 
transformational  prototype  development  view)  of  software  is  generally  accented  as 
inevitable.  To  be  able  to  change  object  code  in  an  efficient  and  responsi-.e  manner 
(Without  starting  over  from  scratch),  is  a  major  (if  not  the  major)  purpose  for  the 
development  environment.  .At  a  minimum,  the  environment  should  facilitate  the 
archival  of  the  product  in  some  durable  storage  media  from  which  the  development 
process  can  be  recreated  exactly  and  then  evolved.  Since  the  product  is  a  direct  result 
of  the  specific  tools  used  to  create  it  (and  the  tools  themselves  are  programs  which  are 
not  provably  correct  or  identical),  the  only  guaranty  that  a  recreation  from  the  archives 
IS  precisely  the  same  product  is  if  precisely  the  environment  used  in  the  software 
engineering  process  is  also  recorded  in  the  archival  process.  If  the  environment  is 
subject  to  creeping  evolution  the  task  of  archiving  becomes  very  complex  as  multiple 
versions  of  a  tool,  or  even  totally  different  tools,  may  have  been  used  in  developing  the 
same  or  dilTerent  parts  of  the  product  at  the  same  or  different  times. 

1 2)  Disjoint  Environment.  While  each  tool  may  add  to  overall  productivity 
in  a  speci.^ic  way.  the  additional  overhead  involved  in  using  a  disjoint  environment  will 
result  in  the  overall  productivity  gain  being  less  than  the  sum  of  its  pans.  In  contrast, 
svnergistic  gains  in  productivity  and  quality  should  be  expected  from  integrated  tools 
I  e.g..  a  debugger  which  works  with  an  object  created  by  an  editor,  as  source  code,  and 
IS  capable  of  changing  the  object  without  forcing  the  user  to  shift  modes  (leave  the 
debugger  and  re-enter  the  editor  to  make  the  change)). 

(3)  Inconsistant  User  interface.  With  rare  e.xceptions.  the  user  interfaces 
from  one  vendor  of  software  to  the  next  vary  considerably.  While  many  argue  that 
tins  is  onh  of  concern  with  novice  users  who  must  learn  a  large  number  of  interfaces  at 
the  same  time,  we  feel  it  is  a  major  consideration  for  expert  users  as  well.  The  expert 
user  may  make  fewer  mistakes  than  the  novice  because  he  knows  which  knobs  operate 
the  svstem  m  each  of  the  modes  of  operation  imposed  by  the  various  dis;oin:  tools. 
But.  tiiere  is  a  cognitive  investment,  in  navigating  this  modal  hierarchy,  which  must 
detract  from  tiie  creative  work  the  UNer  is  trying  to  accomplish  in  the  process.  Also. 


the  training  overhead  required  to  create  expert  users  (including  acceptance  of  the  new 
environment  by  existing  users  in  the  first  place)  will  be  much  higher  than  wuh  a 
consistant  user  interface. 

2.  Long  Term  Off-the-shelf  Buy  Approach 

a.  Advantages 

(1)  Long  Term.  Since  this  approach  involves  a  complete  environment,  we 
are  talking  about  a  major  investment  in  both  hardware  and  software.  Once  such  a 
system  has  been  procured  it  is  likely  to  remain  quite  stable  for  relatively  long  periods  of 
time.  Because  of  its  large  mass  as  an  investment  it  will  tend  to  have  a  great  deal  of 
resting  inertia.  The  developers'  changes  will  be  consistant  with  the  overall  design  to 
protect  the  users  investment.  Creeping  evolution  is  unlikely,  and  any  evolution  is  .more 
easily  traceable  due  to  reduced  complexity  in  the  number  of  vendors  involved. 

(2)  Integrated  Resources  (within  this  CASE  environment).  One  should 
expect  synergistic  gams  in  productivity  and  product  quality. 

(3)  Consistent  User  Interface.  .A  consistent  user  interface  is  not 
guaranteed  just  because  the  environment  is  the  product  of  a  single  developer.  Neither 
is  it  prevented  if  more  t.han  one  developer  is  involved.  Since  there  are  a  variety  of 
Dossibilities.  and  no  one  well  accepted  standard,  it  takes  a  committment,  by  the  lead 
developer,  to  a  consistent  interface  philosophy.  One  relatively  successful  approach  to 
this  is  the  Apple  \(aciniosk  interface.  While  Apple  themselves  followed  a  consistent 
interface  .  they  also  invested  in  the  future  by  providing  the  tooiho.x  of  resource-;,  in 
system  firmware,  which  make  it  easier  for  application  developers  to  simply  conform 
with  the  Macintosh  interface  than  to  invent  so.mething  new  and  different. 

b.  Disadvantages 

1 1 )  High  Cost.  This  approach  requires  an  up-front  committment  to  a 
major  hardware  software  system  representing  a  major  investment  of  funds  relative  to 
that  involved  for  individual  tools.  Local  approval  and  funding  are  less  likely. 
Jusuiication  of  the  system  to  a  higher  level  of  a  bureaucracy  is  generally  more  formal 
.ind  mkes  longer. 

(2)  Sole  Source.  Unless  his  product  has  a  well  established  market  ->;'.arc 
and  the  vendor  is  clearly  a  healthy  'ousiness  concern,  there  is  a  great  risk  in  a  major 
investment  in  his  product.  (No  one  wants  to  be  the  first,  and  possibly  only,  customer.' 
This  risk  is  e'.  en  greater  if  the  product  involves  a  unique  hardware  architecture  required 
to  host  the  environment.  The  user  may  be  elTectively  limited  to  the  \er.dor  s 
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technological  and  proprietar\’  vision  both  for  what  is  included  in  the  environment 
today  and  how  it  will  evolve  in  the  future.  The  resting  inertia  which  makes  this  a 
stable  long  term  asset  may  inhibit  extensibility  in  stride  with  the  advancing  state  of  the 
art.  .Also,  an  off-the-shelf  complete  environment  may  include  resources  which  are  not 
applicable  or  useful  for  the  .MSB  software  engineering  process.  The  customer  naturally 
resists  paying  for  something  he  will  not  use 

i3)  Incompatible  Data  Formats  {with  other  development  environments).  It  is 
a  natural  extension  of  the  idea  of  interoperability  within  an  environment,  to  also 
consider  interoperability  between  different  environments.  If  for  example  MSB  is  tasked 
to  prototype  a  proposed  change  to  an  embedded  software  product  developed  for  a 
project  by  some  contractor,  the  process  would  be  significantly  enhanced  if  the  MSB 
CASE  environment  could  accept  and  operate  on  the  model  of  the  system  and  all  of  the 
objects  developed  in  the  contractors  original  software  engineering  process  and 
environment. 

3.  Make  Approach 

The  make  approach  shares  many  of  the  disadvantages  of  the  long  term  buy 
approach.  In  general  terms  it  appears  to  far  exceed  e.xisting  MSB  resources.  In 
Chapter  IV,  we  will  discuss  some  of  the  inherent  risk  for  any  sole  development  of  a 
C.ASE  environment. 

C.  WHICH  way  from  HERE 

In  order  to  elfectively  make  decisions  which  commit  scarce  resources  to 
developing  a  C.ASE  environment  for  MSB.  managers  in  the  MSB  chain  of  command 
must  understand,  the  software  engineering  problem  and  how  it  relates  to  the 
productivity  of  MSB,  as  well  as  what  a  CASE  environment  is  intended  to  be,  and  do. 
to  improve  productivity.  An  understanding  of  general  C.ASE  environment  development 
issues,  and  principles  for  a  good  C.ASE  environment  will  also  help. 


IV.  CASE  ENVIRONMENT  DEVELOPMENT  ISSUES 


A.  SCOPE  OF  CASE  PROBLEMS 

As  previously  mentioned  there  are  a  number  of  products  on  the  market  which 
use  the  term  CASE  in  their  descriptions  but  only  amount  to  tools,  or  toolsets,  iiinited 
to  a  portion  of  a  full  life  cycle  software  engineering  environment.  A  life  cycle  \;ew  of 
C.ASE  entails  some  major  development  problems  which  are  rellected  in  the  general 
state  of  this  technology  today. 

1.  Evolutionary  Development  Politically  Necessary 

High  risk  is  the  driving  force  behind  evolutionary  development  of  C.ASE 
environments.  Because  of  the  size  and  complexity  of  a  C.ASE  environment,  and  the 
irnimaturity.  instability  or  rapid  evolution  of  the  fundamental  components  involved  (i.e.. 
languages,  database  technology,  management  techniques,  software  engineering 
methods,  economic  models,  hardware  engineering,  graphics,  networking,  ergononucs. 
artificial  intelligence,  etc.),  the  classic  problem.s  of  software  engineering  app!>  to  C.ASE 
environment  development.  Definition  of  the  problem  (the  software  engmeermg 
process)  is  generally  incomplete,  or  inconsistent,  and  likely  to  remain  so  for  'icmci  m.e 
for  the  software  industry  as  a  whole.  ,As  a  result,  no  clear  industn  'vide  w*:  of 
requirements  to  be  satisfied  by  the  environment  has  emerged.  Like-.i^e.  no  vfe.ir 
agreement  on  fundamental  issues  regarding  data  models  and  component  interfaces 
Within  er.Niron.ments  or  among  environments  have  emerged.  Most  ofdcme'-t.c  .r.dustr;. 
seem  to  lack  the  resources  and  motivation  to  undertake  a  fuii  iiie  c'. cic  CASE 
er.\ ironment  de\elopment  project  under  such  high  risk  conditions  (uncertain  cl'  ti.e 
direction  each  of  these  technologies  wiil  take).  As  a  result,  most  elTorts  ha\c  continued 
to  chip  away  at  the  problem  from  the  bottom  up.  The  risk  of  changing  tee'ino.ogv  i^ 
not  likely  to  suddenly  go  away.  The  software  engineering  process  m.i'  he  aoI'.  def.nod 
for  a  particular  organization  in  which  the  rr.a)oru\  of  projects  follow  vimilar  life  c-  ..ev 
However,  it  is  likely  that  several  distinct  cnMionment  markets  exist,  anu  con.niitt.nent 
to  a  single  life  cycle  model  would  constitute  a  committment  to  a  single  veriica.  maiNC’ 


European  developers  seem  to  be  way  ahead 
inteciratcd  fail  life  cveie  CASE  on',  ironments. 
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2.  Requirement  Tradeoffs  Contributing  to  Risk 

Among  the  many  tra^ieofTs  mvoI\ed  in  CASE  requirements  analysis  are: 

•  lo'.v  u’  g  ■  UNIX)  \s,  high  integration; 

•  i.'.Obed  vs.  open  environment  texiensibilitv): 

•  ianguage  dependence  vs.  independence; 

•  incnciingua!  \s.  multiimgual; 

•  partial  \s.  full  liie  cycle  support; 

•  'ingle '.s  multiple  methodology; 

•  s;.ig.e  user  vs.  multiple  user; 

•  hardware  dependant  vs  independent; 

•  text  \s.  gr.iphics; 

•  sv'tem  ccnl'igLirabie  v  s.  user  configurable; 

•  non- secure  vs.  secure; 

•  ^ost  elTei-tive  vs.  tost  e.xorbitant 

‘Henderson.  1‘1S“.  p  J8).  What  is  needed  is  a  committment  to  a  C.ASE  environment 
Jevciopm.en:  ph;losophy  which  will  allow  evolutionary  development  ol'  good 
environments,  ul.iie  mininu/mg  risks  from  changing  software  engineering  prccc's 
rC'- uire.ments  and  continued  technological  advances.  First,  let  s  consider  what 
son.'t.tutes  a  good  automated  environment  for  software  engineering. 

B.  FI  NDAMENTaL  PRI.NCIPLES  FOR  CASE  E.WIRONME.NTS 

The  b..ckground  discussion  of  the  preceding  chapters  included  sever. il  I'vacs 
vi'.ich  have  inl’.ucnced  the  evolution  of  C.ASE  environment  clforts.  We  did  not 
Ju.c.er  ain  ciear  cut  study  or  statistics  proving  one  side  of  certain  issues  to  be 
'..pen or  to  the  ether.  One  can  get  a  feel  for  the  trend  of  developments,  u'cr 
.i^.eptance  and  tlie  direction  of  ongoing  research,  by  e.xamining  past  and  continuing 
uerk  '.'..th  env iron.monts.  A  strong  dose  of  corranon  sense  can  then  be  applied  to  tite 
."t.es.  and  ehewes  can  be  made  which  appear  to  be  fundamcntallv  better  tnan  tlte 
aiterr.at.v  es  .An  objective  studv  to  demonstrate  that  these  choices  are  superior  to  tf.cir 
.itrr!..i,.ves  is  certain.y  a  direction  for  further  research,  but  far  exceeds  the  '-.ope  o: 


'cem'  tiiat  few  such  'tudies  are  ever  conducted.  Such  a  studv  n.ui't 
i^l'.ow  .n.'.plcment.ition  ol'  'he  principles  involved.  Ihen  e...h  h 
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need  to  re  applied  in  parallel  to  the  same  problem  in  an  cnv.rc 
vjri..ble'  ('Ctf.vure.  ha.'dware.  people,  etc  ;  arc  ecntroilcd  ■  no 
exrer.'iv  e'.  .As  i.a'  often  been  the  case  with  past  devoiopnient',  ;1  .1 
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Leon  Osienveil  (1981,  pp.  36-37)  wrote  that. 

The  essence  of  a  software  environment  is  the  synergistic  integration  of  tools  in 
order  to  provide  strong,  close  support  for  a  software  job.  This  environment  must 
have  at  least  these  five  characteristics:  breadth  of  scope  and  applicability,  user 
friendliness,  reusability  of  internal  components,  tight  integration  of  capabilities, 
and  U'^e  of  a  central  information  repository.  A  support  system  must  possess 
tl'.ese  characteristics  if  it  is  to  merit  the  name  enviromneni. 

This  'iix  year  old  view  of  what  should  characterize  an  environment  has  not  generally 
been  attacked  or  disproved,  seems  to  represent  the  consensus  of  todays  stated  goals  for 
environments,  and  is  the  essence  of  what  we  call  fundamental  principles  for  C.ASE 
environments. 

1.  Portable/ Reusable  CASE  Resources 

\Ve  view  environments  as  a  collection  of  resources.  The  collection  includes; 

•  physical  resources,  consisting  of  computer  hardware  and  system  software  and 

firmware; 

•  C.\.SE  resources.  consisting  of  software  tools  implemented  on  the  physical 

resources: 

•  manual  resources,  consisting  of  the  methods  and  procedures  necessary  to  the 

software  engineering  process  but  not  implemented  as  C.ASE 
resources; 

•  human  resources,  consisting  of  the  people  who  use  and  facilitate  utilization  un 

tile  case  of  manual  resource'  of  the  environment. 

Our  ;'r  m..ir>  focus  ;s  on  C.-\SE  resources.  Naturally,  the  CASE  resources  imply  the 
r'^mn.uin  pnv  s.^ui  resources  required  for  their  execution.  They  also  define  the 
'.u'.u;: boundaries  for  a  software  engineering  process  in  a  given  ont  ironment 
li.c'c-''.  ue;errr.ir.:rig  the  nature  of  manual  and  human  resources. 

C.\SIi  resources  should  provide  the  software  engineering  team  (human 
i'evrur.e''  ith  a  problem  solving  interface  between  the  real  world  problem  (for  which 
;;;e'.  im.^t  deselop  a  software  solution)  and  the  manual  and  physical  resources.  A 
"niad.  shallow,  functional  hierarchy  of  resources,  is  required  to  support  user 

i.ke  prouuctivity  (which  is  inherently  dilTicult  to  quantify  with  precision)  is  noticeably 
impr.j-. ed  bv  the  change,  the  industry  tendency  seems  to  be  to  accept  and  exploit  the 
change.  If  the  ads  antage  of  the  change  is  not  clear,  it  is  resisted  and  either  limps  along 
uith  a  minor  market  share  or  dies  out  by  natural  selection.  In  cither  case  there  seem 
tc  have  been  lew  attempts  to  objectively  quantily  the  relative  advantage  o;  the 
alternatives  involved.  .A:  best,  emp-rical  oru'er  >./  fuaguiiuJe  comparisons  of  s;iv.;:,;r 
.ssues  are  conducted. 
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goals  (discussed  later).  By  shallow,  we  mean  a  hierarchy  with  ver>’  few  layers.  This 
facilitates  responsiveness  by  reducing  the  calling  overhead  required  to  descend  through 
the  hierarchy  in  order  to  use  physical  resources.  Subordinate  layers  in  such  a  shallow 
hierarchy  will  be  bread  in  the  sense  that  they  will  of  necessity  contain  many  resources 
(if  modular  design  principles  of  coupling  and  cohesion  are  observed).  In  such  an 
architecture,  kernel  utility  resources  (with  unique,  independent  functionality)  direct, > 
access  tiie  iiardware  resources  or  the  environment  data  model  (the  key  C.ASE  rcsou,'cc'. 
on  behalf  of  tool  resources  which  proside  C.ASE  environment  services  to  tiie  user 
interface.  Such  an  architecture  enhances  portability  and  reusability  of  software 
components  and  e.xtensibility  of  software  systems. 

The  issues  of  portability  and  reusability  of  CASE  resources  and  extensibility  of 
C.ASc  environm.ents  are  fundamental  to  risk  management.  C.ASE 
envircnrv.cr.t  resource  user  risk  will  be  reduced  if  their  investment  is  secured  well  ;ntc 
the  future  imspite  of  hardware,  methodology,  and  other  technological  advances i. 
C.ASE  environment  resource  developer  risk  is  reduced  if  their  products  reach  a  broader 
market  -  various  hardv.are  and  methodologies)  with  greater  longevity.  L'nfortunateh . 
•site  same  competitive  m.arket  dynamics  which  encourage  technological  innovation  tend 
:c  discourage  reusability  and  portability.  Hardware  and  software  developers  uhe  rei;. 
heavily  cn  the  direct  linkage  of  their  respective  products,  to  control  their  share  of  tiie 
market,  tend  to  resist  (often  in  subtle  ways)  industry  standardization  elTorts  unKh 
m.ight  undernune  their  market  leverage. 

2  Integrated  C.ASE  Resources 

.All  oi'the  C.ASE  resources  in  an  environment  should  be  integrated  to  facilitate 
-.ltereni.e.  control  and  sharing  (see  Chapter  11)  in  order  to  y)eid  a  synergistic  c;lect 
'.'.here'''y  the  utility  cf  the  environment  as  a  whole  is  more  than  just  the  vum  :t^ 
parts.  Recali  that  with  respect  to  automated  environment  tools,  in  this  uu-tan.-c  C.AST 
rc'Curces.  ue  def.ned  integrated  as: 

•  aii  resources  conform  to  a  consistant  user  interlace; 

•  ill  resources  are  as  highly  interoperable  av  possible: 

•  c'jects  and  their  interrelatior.'hips  are  in  a  persistent  common  data  forn.at. 

■.'■  Inch  IS  n'.caninglui  to  ail  cn’. iron.ment  resources. 

The  ccn'istcnt  user  interface  and  interoperability  allow  for  intuitive  access  to  ('.\Sl 
re^ourues  relieving  the  user  of  much  of  the  cognitive  overhead  of  navigating  .mtettg 
■. anous  tools,  vv.th  various  operating  centrals.  'I he  user  can  devote  more  a:  I'..'- 
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attention  to  the  software  engineering  task  at  hand.  Interoperability,  based  on 
manipulation  of  the  common  data  model  by  all  CASE  resources,  should  allow  the  user 
to  create  or  change  an  object  by  manipulating  any  of  it  s  displayed  forms, 

(  MacI.ennan.  p.  l-.'l 

Open  Environment 

To  enjo>  the  benefits  of  new  technology  and  competitive  cndeasor.  and 
encourage  e\ olutionars'  development  for  multiple  environment  mar.kets,  environments 
should  be  open  to  extensibility.  To  support  reusability  of  resources,  functionality  of 
existing  C.AST  resources  should  not  be  diminished  by  new  resources.  To  reconcile 
extensibility  with  the  seerrungly  conflicting  principle  of  integration  requires  agreement 
on  and  'standardization  of 

•  data  .model  used  to  represent  objects  and  their  interrelationships; 

•  interfaces  of  C.ASE  resources  with  the  data  model;  ^ 

•  interfaces  of  C.ASE  resources  with  physical  resources; 

•  interfaces  of  C.ASE  resources  with  the  user. 

-  L  ser  Friendly 

L  ser  Iricndly  is  a  much  over.vorked  term,  but  we  ve  chosen  to  use  it  !'or 
consis;en<.>  with  Oster.veil.  Conxmitment  to  an  integrated  C.ASE  environment 
composed  of  C.ASE  resources  as  described  above  can  lacilitate  an  event-driven  -'cr 
interface  phi.osorhx.  Such  a  philosophy  i'  characterized  by. 

•  responsiveness,  U'cr  s  actions  have  direct  results,  arc  intuitive  and  spontaneous 

I  i.c  .  no  inodes  i; 

•  perrruss;\eness.  the  user  can  do  ar.vth.ng  reasonable  at  ar.v  time,  the  user  decides 

what  to  do  next,  not  the  individual  C.ASE  rcsourv.e  m.c  .  no 
modes); 

•  consistency.  regardless  of  what  C.ASE  resource  is  in  execution,  the  user  s 

control  options  and  the  apparent  response  to  them  arc  ..ons. stent 
with  the  tvpe  of  function  being  performed  le.g..  anvthir.g  tin;: 
seems  like  text  editing  should  use  identical  controls  regardless 
whether  it  involves  labeling  a  grapnical  diagram  or  general. ng  a 
textual  document' 


The  dutaba.se  provides  an  integrating  and  unliving  m.edium.  I'or  interfacing  tools 
without  ;or>;ng  titem  into  a  complex  structure  of  interrelationships.  l  ocls  obt.un  titeir 
m; .m:n..t;on  :i'cm  the  database  and  return  their  results  to  it  witiiout  huvmg  to  .menace 
uirc^ip.  w;t;i  o'ner  tools.  ...  in  order  to  maintain  Ilextbiiitv  it  is  '.mpertan'  ...r.d 
budding  '.'ridges  'petween  purs  of  tjc.s  ratiicr  than  bridges  into  the  d.i:.:'''..se  " 
ilovvden.  Ibx:.  p.  cdOi 
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The  feel  of  such  an  interface  should  be  that  the  environment  is  waiting  to  serve  the 
user  as  opposed  to  the  other  way  around.  This  is  done  by  employing  an  event-driven 
control  structure  where  user  actions  are  events  and  the  system  is  always  ready  to 
handle  them  (e.g..  as  priority  interrupts,  or  by  polling  for  them).  The  broad  shallow 
architecture,  of  the  CASE  resources  in  the  environment,  facilitates  event  handling 
without  modality. 

C.  FLNCTIONAL  ABSTRACTION  AN  APPROACH  TO  SOLVING 

PROBLEMS 

The  principles  may  not  have  changed  significantly  in  si.\  years,  but  C.ASE 
environments  embodying  these  principles  are  not  generally  available.  Without 
belaboring  the  point,  we  attribute  this  to  the  high  risk  of  building  on  questionable 
standards  in  rapidly  changing  and  relatively  immature  technologies.  We  propose  a 
strategy,  to  avert  some  of  said  risk,  allowing  progress  towards  these  principles. 

1 .  Definition  of  Abstraction 

.An  abstraction  is  a  description  of  some  object  which  separates  the  de.^ining 
properties  of  the  object  from  the  unnecessary  details  about  it.  A  software  engineer  is 
concerned  with  solving  seme  problem.  The  tools  (C.ASE  resources)  in  his  software 
engineering  environment  .^o.'m  a  probUm  solving  abstraction.  The  hardware  (and  some 
of  the  software!,  on  which  tiie  problem  solving  abstraction  (the  C.ASE  resources!  -re 
implemented,  form  a  physical  resource  abstraction  (  Yurchak,  1984.  p.  Si. 

2.  Formal  Specification 

It  IS  generally  recognized  that  the  operating  system  is  an  abstraction  of  tiie 
hardware  system  of  primary  and  secondary  memory  resources,  processor  resources,  and 
input  output  resources.  .Additional  abstractions  (c.g..  video  display  resources'  ha'. e 
ai.so  become  commonplace.  Such  abstractions  generally  e.xhibit  la  of  formalism  or 
coriSi>tency.  a  semantic  gap.  similar  to  the  problems  faced  by  linguists  trying  to  specifv 
the  semantics  of  language  constructs.  "The  vital  property  of  a  specificaticn  which 
guarantees  that  a  correct  program  corresponding  to  n  may  be  constructed,  is  ...  .  its 
C'>-!s..sicijcy."  (Lehman.  1984.  p.  39,i  The  practical  problem  to  be  soived  .rnoivc'-  ti.e 
pcrt-bility  of  software.  One  must  be  able  to  specify  resources,  in  an  implement  iticn 
inuependent  manner,  in  terms  of  abstract  functional  properties  they  provide,  Davis 
using  concepts  developed  to  specify  the  semantics  of  h.igh  level  language 
constructs  (particularly  abstract  data  types',  developed  a  m.ethod  for  alge^'raic 
spccifwacion  to  solve  some  of  these  problems.  L'sing  such  a  formal  specification  as  an 


external  frame  of  reference,  correctness  of  a  program  developed  from  the  specification 
can  be  viewed  as  a  calculable,  instead  of  empirical,  notion  (Lehman.  19S4.  p.?9).  The 
implication  is  that  a  correct  implementation  of  a  problem  solving  resource,  layered  on 
top  ot'  correct  implementation  of  physical  resources,  will  always  behave  functionally  the 
same  regardless  of  the  implementation  or  hardware  details.  The  way  is  then  clear  for 
development  of  portable,  reusable,  functional  resources. 

3.  Abstraction  of  Physical  Resources 

'I'urchak  (19S4)  used  Davis's  algebraic  formalism  to  specify  .AM.  an  abstract 
machine  i physical  resource)  from  functional  requirements.  Multiple  instances  of  .AM 
have  been  successfully  implemented,  from  'V'urchak's  specification,  on  different  physical 
hardware  at  Naval  Postgraduate  School.  Implementation  efforts  proceed  quickly  and 
.Tie..hanically  without  the  semantic  ambiguity  of  less  formal  specifications.  Work  is 
continuing  testing  portability  of  applications  running  on  .AM  when  hosted  by  different 
physical  hardware. 

Grant  (1986)  functionally  abstracted  resources  to  support  graphic  user 
interfaces.  He  hosted  his  abstract  resources  on  the  Apple  Macintosh  and  Digital 
Rc'carch  s  GCM  'on  the  IBM  PC).  .Applications,  using  only  his  abstract  resources, 
are  portable  between  the  two  host  implementations  inspite  of  significantly  diiferer.t 
hardware  and  system  software  te.g..  differences  between  color  and  monochrome  a.'-e 
handled  by  the  abstraction  by  placing  colors  within  a  gray  scale,  from  light  tc  dark, 
causing  them  to  be  cisplayed  in  logical  shades  of  gray  when  hosted  on  monochrome 
r.ard'.v.w'c. ).  There  is  no  noticeable  (from  a  human  interaction  perspective i  degradation 
in  the  response  time  of  applications  using  Grant's  abstract  resources  vs.  similar  native 
system  resources  (c.g.,  mouse  tracking)  on  either  host.  This  is  attributed  to  Grant  s 
adi'.erence  tc  the  broad  shallow  architecture  principle  for  portable  reusacie  resources 
supporting  user  friendliness.  .At  most  two  levels  of  calling  overhead  are  added  between 
an  application  resource  call  and  the  native  system  resources. 

4.  .Abstraction  of  Environment  Resources 

By  defining  abstractly  the  basic  functionality  of  C.ASE  resources  based  cn  a 
useful  standard  data  model,  and  implemented  on  abstract  hardware  resources,  scfi.s.irc 
Jeveiopors  may  be  able  to  drive  C.ASE  development  with  nunima!  risk  from,  the 
u.n.eitainties  of  hardware  evolution,  language  evolution,  and  even  evolution  oi  tiie 
soft’.vare  engineering  process.  One  key  is  agreement  on  a  standard  data  medei  capaolc 
of  representing  ail  of  the  objects  (i.e..  real  like  people,  programs  and  dccuments,  or 
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imaginan-  like  yei  undeveloped  programs  or  unhired  people)  and  their  inter¬ 
relationships  which  compose  the  software  engineering  environment.  C.ASE  resources 
must  assume  basic  hardware  and  system  capability  as  specified  for  the  abstract 
hardware  resources.  Once  a  C.ASE  resource  is  operational  on  the  abstract  hardware,  it 
would  be  portable  to  any  physical  hardware  capable  of  hosting  the  abstract  hardware. 
Given  an  abstract  hardware  host,  fully  integrated  environments  could  be  assembled 
from  abstract  C.ASE  resources.  .An  environment  builder  could  design  and  implement 
his  own  preferred  consistent  user  interface  which  interacts  with  the  abstract  C.ASE  and 
physical  resources.  But,  ideally  he  would  find  it  easier  to  adhere  to  user  interface 
guidelines  making  use  of  C.ASE  resource  utilities  which  directly  and  elliciently  use  the 
abstract  physical  resources  to  provide  a  responsive,  permissive,  consistent,  human 
engineered  user  interface.  New  resources  could  be  abstracted,  as  technology  advances, 
by  adhering  to  the  specified  data  model  and  interfaces. 

Such  an  aproach  is  directly  pointed  to  by  efforts  such  as  C.AIS  and  PCTE. 
We  believe  efforts  in  this  direction  hold  some  promise  for  bringing  order  to  the  current 
environment  chaos. 

5.  Layers 

The  question  of  efficiency  often  comes  up  in  connection  with  our  advocacy  ol 
layc.'ing  abstract  problem  solving  resources  on  top  of  abstract  physical  resources  on 
top  of  actual  physical  resources.  This  is  certainly  an  area  of  concern  since 
responsiveness  is  one  of  our  user  friendly  requisites,  and  many  C.ASE  resources  may  be 
physical  resource  intensive  (e.g..  manipulation  of  many  interrelated  objects  in  a  large 
project  database).  .A  key  to  this  issue  is  our  advocacy  of  a  broad  shallow  hierarchy  of 
C.ASE  resources  facilitating  responsiveness  of  event  driven  user  interfaces  and  resource 
intensive  tools,  and  providing  rapid  access  to  physical  resources  by  avoiding  a  deep 
modal  hierarchy.  Grant's  e.xperience  indicates  that  this  can  be  a  viable  approach  for 
supporting  user  friendliness  in  an  interactive  graptiic  user  interface.  The  speed  of 
physical  resources  has  been  continuously  increased  by  hardware  advances,  and  more 
recently  through  multi-processor  architectures.  so  it  seems  reasonable  to  argue  tliat 

^^.As  an  example,  the  Multi  Ba>.kend  Database  System  tMBDS)  at  the  Naval 
Postgraduate  School  provides  for  distributing  a  database  evenly  among  multiple  oif- 
the-she.f  backend  microcomputers.  Database  size  can  be  doubled,  with  no  impact  on 
transaction  time,  if  the  numoer  of  backends  is  doubled.  Or.  the  response  tune  cun  be 
halved  by  doubling  the  number  of  backends  while  maintaining  database  si/e.  The 
number  of  backends  is  transparent  to  the  users  who  deal  with  MBDS  as  an  abstract 
database  resource  which  supports  multiple  data  models  and  multiple  query  ianguage^. 
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small  efficiency  gains  in  CASE  resource  implementation,  at  the  cost  of  portability  and 
reusability,  are  likely  to  be  wasted  in  the  long  run  (i.e.,  if  you  must  scrap  non-portable 
resources  in  order  to  take  advantage  of  more  significant  performance  gains  offered  by 
technological  advances). 

In  addition  to  efficiency  considerations,  a  major  consideration,  in  constructing 
abstract  resources  is  identifying  the  individual  functions  to  be  provided.  .As  Oster.veil 
tl9Sl,  p.  3")  observed,  different  application  areas  will  inevitably  lead  to  differences  in 
environments  to  support  them.  The  bottom  layer  of  problem  solving  resources  should 
be  atomic  functions  which  directly  support  multiple  top  layer  resources.  .-\s  an 
example,  an  atoirac  resource  might  be  a  parser  which  is  called  by  pretty  printers,  error 
checkers,  static  analyzers  and  compilers,  etc..  The  philosophy  for  developing 
environments  should  use  information  hiding  to  protect  the  integrity  of  these  basic 
layers.  In  other  words,  the  users  of  top  level  resources  only  interact  with  tho^e 
resources.  For  instance,  the  compiler  user  should  only  use  the  compiler.  The  fact  that 
the  parser  even  exists  should  be  hidden  from  him.  Those  abstracting  top  le\el 
resources,  know  the  parser  exists,  but  only  access  the  parser  in  terms  of  it^  abstract 
functional  interface.  If  the  need  arises  to  jump  around  a  layer  of  abstract  resources  to 
get  at  some  lower  function,  then  a  function  which  should  have  been  abstracted  has 
been  missed.  This  is  one  reason  why  high  order  languages  like  .Ada  or  Pascal  den  t 
produce  portable  applications.  .Abstraction  m  these  languages  is  at  an  extremely  high 
level  (the  programming  logic  level),  and  hardware  or  operating  system  calls  arc  often 
required  to  handle  external  interfaces  (e.g..  input  output  devices).  In  the  case  of  good 
program  design  these  may  be  collected  into  abstract  interface  packages  and 
documented  as  requiring  change  before  porting.  By  abstracting  at  a  lower  le-. el.  and 
being  conmutted  to  a  philosophy  preserving  the  integrity  of  layers  of  resource 
ab'tractior.s.  portability  and  reusability  of  environment  resources  may  be  achieved, 

n.  Standards  Enforcement  vs.  Encouragement 

One  t.hmg  the  software  industry  has  is  plenty  of  standards.  .As  par'  o:'  the 
criginai  ST.ARS-SEE  e.Tort.  Insiiiuie  for  Defense  Analyses  conducted  a  '■tudv  of 
infcrm.atior.  interface  related  standards.  They  identified  ~”2  existing  standard';  and  d22 
emerging  standards  **  from.  77.  international.  L'.S.  government,  or  indu<urial. 
organizations.  The  study  focused  on  standards,  in  25  categories  (e.g..  data  intcrciiange. 

■’The  categcrx'  of  emerging  standards  included  both  standards  oriented 
develcrment  projects  and  commercial  ventures  beconung  detacto  standards  by  s;rtac  .U 
market  share. 
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project  management,  graphics,  programming  languages,  etc.),  considered  of  possible 
relevance  in  defining  integration  requirements  for  the  STARS-SEE  (Nash.  19S5.  p. 
::?). 

The  fact  that  so  many  standards  exist,  and  so  many  more  are  developing 
suggests  that  standards  are  anything  hut  standard.  Many  standards  are  the  result  of 
noble  cHort  by  standards  organizations.  But,  adherence  to  such  standards,  by 
developers,  can  be  a  high  risk  proposition.  If  the  standard  is  something  new  and 
dilTerenc,  there  is  no  easily  predictable  market  for  a  product  conforming  w.th  it. 
Success  of  such  a  product  (its  market  capture)  is  determined  by  a  multitude  of  factorc. 
If  the  product  is  measurably  or  noticably  superior  to  some  existing  successful  product, 
or  provides  some  entirely  new  and  highly  demanded  function,  and  is  targeted  for 
physical  resources  commanding  a  significant  portion  of  the  likely  user  group,  it  will 
probably  be  successful.  This  is  risky  business,  and  many  standards  on  paper  never 
become  standards  in  fact.  Some  standards  of  necessity  (e.g.,  hardware  interconnection, 
external  communication  protocols,  etc.),  many  of  which  began  as  defacto  standards, 
are  broadly  accepted  as  mutually  beneficial  to  industry  as  a  whole.  Other  standards, 
such  as  those  promoting  software  portability  (in  this  case  CASE  resources),  may  be 
Viewed  favorably  by  users,  and  developers  without  a  vested  interest  in  particular  real 
physical  resources.  However,  much  market  selection  of  hardware  currently  in',  olves 
issues  concerning  the  breadth  and  depth  of  software  applications  available  for  that 
iiardware.  If  software  were  more  readily  portable  and  reusable  a  major  hardware 
marketing  lever  would  be  altered  significantly. 

.As  stated  earlier,  hardware  and  software  developers,  who  rely  heavily  on  the 
direct  linkage  of  their  respective  products  to  control  their  share  of  the  market,  tend  to 
resist  (often  in  subtle  ways)  industry  standardization  efforts.  If  their  market  'Iture  is 
large  enough,  they  collect  strap  hangers  seeking  some  of  that  market.  It  is  in  tins  way 
that  dcfacto  standards  arise.  Of  course,  at  this  point  the  authors  of  the  del'acto 
standard,  who  have  already  profitted.  may  change  directions  radically  in  a  bid  to  •.hake 
olT  strap  hangers  who  have  not  yet  recouped  their  investment.  .And  so.  often  '.vith 
dnferent  lesser  players,  the  cycle  begins  again. 

In  a  few  cases,  such  as  the  DcD  .Ada  initiatives,  a  particular  standard,  or  set 
of  standards,  have  been  implemented  and  enforced  by  management  dictate.  In  tlie 
case  of  .Ada.  competition  for  DoD  dollars  has  been  the  primar.  industry  incentive  to 

'■One  may  argue  that  .Ada  is  far  from  being  fully  implemented,  and  that 
management  resolve  is  not  pertccth.  clear. 


actually  develop  the  resources  required  to  support  the  dictated  standard.  One  ob\  ious 
drawback  to  tnis  sort  of  approach  to  standardization  is  the  fact  that  few  interest 
groups  have  the  financial  ck'U[  required  to  pull  something  like  this  off.  A  more  subtle, 
and  in  the  long  run  possibly  detrimental,  drawback  (to  standards  by  edict)  ;s  the 
possibility  that  the  standard  may  not  be  a  very  good  one,  but  gains  momentum  by 
directive,  and  consumes  resources  which  might  otherwise  contribute  to  esolution. 
through  natural  selection,  of  something  better.  .And.  once  in  place,  inertia  wdl  tend  to 
keep  it  there.  Of  course,  if  the  standard  is  good,  or  at  least  acceptable,  the  advantages 
cf  focusing  resources  and  elfort  should  be  significant. 

The  dilcma  of  standards  enforcement  vs.  encouragement  is  not  likely  to  be 
resolved,  ^^■e  favor  standards  encouragement  for  C.ASE  resource  functional 
abstraction,  interfaces,  and  data  models.  Keys  to  standards  encouragement  are: 

•  good  design.  so  there  is  little  incentive  to  repeat  the  effort: 

•  availability,  if  possible  make  all  forseeable  low  level  resources  sufTiciently 

eiTicient  and  readily  available  so  there  is  little  incentive  to  violate 
layer  integrity  iby  jumping  around  it),  and  little  inccnti\e  to 
rein':ent  liu'  \.vheel 


•  guidelines.  '.veil  publicised  and  justified  philosophy  of  why  it  is  the  wa\  i:  is 

and  hew  to  keep  it  that  way. 

•  social  change,  growing  recognition  that  standards  promoting  plug  compaiibkay  of 

C.ASE  resources  with  eachother,  users,  and  physical  resources,  arc 
also  standards  of  necessity. 

"  Top  Do«n  or  Bottom  L'p 

One  cf  our  major  criticisms  of  the  current  state  of  most  C.ASE  environment 
development  has  been  the  bottom  up  path  being  followed.  We  ve  recognized  sorr.e  cf 
the  motivation  for  this.  Commercial  C.ASE  developers  are  avoiding  risk  and  playing  to 
the  disjoint  oif-the-shelf  tools  market.  In  order  to  survive,  software  de\ elopers  (C.ASE 
rosourve  users  customers)  in  the  competitive  trenches  often  require  immediate  support 
I  some  ol'  which  is  available  in  disjoint  olT-thc-sheif  tools).  One  significant  bc-prcduct 
ffroni  the  long  term  view)  of  this  activity  has  been  the  generation  cf  experience,  wun  a 
varietx  of  capabilities,  as  a  base  for  identifying  problem  solving  resource  funi.ticns  for 
•ibstraction. 

The  top  down  activity  in  our  C.ASE  environment  development  strategy  begins 
with  the  analysis  of  a  basic  software  engineering  process  to  abstractly  spccily  I'ne  di.ta 
model  and  interface  requirements  iv.hich  are  the  infrastructure  of  the  en\ ircnmcnt  >. 
and  the  I'unetions  (at  lower  layers,  and  their  aggregate  tat  successive  higher  i.r. ers.. 
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which  together  with  the  type  of  data  they  manipulate,  define  the  resources  of  the 
environment.  Design  then  proceeds  hierarchically  with  more  comple.x  resources 
specified  in  terms  of  more  primitive  resources  in  the  adjacent  lower  layer.  Algebraic 
formalism  associates  meaning  to  the  specification  of  each  resource,  with  a  rigor  which 
can  be  used  to  calculably  verify  implementations  of  the  resources  defined  in  the 
specifications  {Davis.  19S7,  pp.  30-2  -  30-7). 


V.  FtNCTIONAL  REQUIREMENTS  ANALYSIS  ISSUES 


A.  SCOPE  OF  THIS  EFFORT 

In  Chapter  IV,  we  discussed  CASE  environnaent  development  issues  and  their 
contribution  to  the  existing  chaos  of  disjoint  tools,  toolsets,  and  environments.  We 
discussed  general  principles  for  good  environments  and  how  abstraction  of  resources 
and  a  formal  .method  of  algebraic  specification  may  help  to  achieve  those  principles 
and  alleviate  continuing  chaos.  We  believe  that  this  approach  should  be  developed 
further  to  make  good  C.ASE  environment  resources  which  become  the  foundation 
building  blocks  of  portable,  reusable,  interoperable  CASE  environments. 

In  virtually  all  conceivable  software  engineering  processes,  staning  from  the  top 
means  analysis  of  the  real  world  problem  to  be  solved.  It  is  clearly  beyond  the  scope 
of  this  work  to  conduct  an  in  depth  analysis  of  the  process  required  by  .MSB.  and  the 
functional  hierarchy  of  C.ASE  environment  resources  required  to  support  the  process. 
Wi'.at  we've  done  so  far.  falls  more  in  the  category  of  general  .fiimiliarization.  It  is 
potentially  useful  as  a  starting  point  for  more  directed  effons. 

In  Chapter  III.  we  outlined  three  basic  alternatives  for  .MSB  C.ASE  environment 
procure.ment: 

•  make; 

•  short  term  o:T-the-shelf  buy; 

•  long  term  ofl'-the-shelf  buy. 

We  also  indicated  that  the  make  alternative  very  likely  exceeds  .MSB  resources  and  is 
tlicre.''ore  infeasible.  However,  we  would  like  to  carry  the  make  ideas,  discussed  in 
Chapter  IV,  a  little  further  to  illustrate  some  of  the  top  level  considerations  involved. 
We  are  going  to  skirt  the  really  difficult  issues  of  a  standard  data  model  (based  on  t'ne 
software  engineering  process  whose  defimtion  we've  also  bv passed)  and  a  data 
ex.itange  interface  (at  a  higher  level  than  sequential  character  based  text  files).  We  will 
look  at  some  functional  design  issues  for  a  relatively  well  understood  subset  of  C.ASE 
environment  resources  supporting  individal  programmer  productivity  (IPP).  '■ 


“This  is  not  intended  to  appear  like  the  type  of  bottom  up  effort  we  have 
criticised,  We  proceed  in  this  fashion  because  of  time  constraints,  the  exploratory 
SvOpe  of  this  effort,  and  the  extremch  broad  scope,  complexity,  and  uncertaintx  of  tr.e 
environment  engineering  task  (which  has  contributed  to  the  current  chaotic  state  of 
ein ironment  automation  in  general).  Our  intended  purpose  is  to  advance  understanding 
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It  is  noteworthy  that,  with  the  layered  approach  we’ve  advocated,  most  of  the 
low  level  resources,  required  to  support  a  subset  like  IPP,  are  also  required  support  for 
other  high  level  tools.  As  an  e.xample,  all  of  the  user  interface  resources,  below  the 
C.ASE  tools  resource  layer,  must  be  in  place  (as  do  the  user  interface  guidelines).  IPP 
tool  resources  will  use  the  user  interface  physical.  CASE,  and  manual  (i.e..the  user 
interface  guidelines)  resources,  just  as  all  subsequent  tool  resources  should  use  them,  as 
the  basis  for  the  consistent,  user  friendly  interface  which  is  one  fundamental  attribute 
of  an  integrated  environment.  This  sort  of  idea  should  help  one  to  visualize  tlic 
potential  contribution  of  our  approach  towards  open  extensible  environments  without 
compromising  integration. 

B.  I.NDIVIDL  AL  PROGRAMMER  PRODUCTIVITY  (IPP)  RESOURCES 

What  follows  is  a  very  broad  brush  treatment  of  a  few  of  the  concerns  associated 
with  functional  abstraction  of  C.ASE  resources  for  a  small  part  of  a  C.ASE 
environment. 

1.  Physical  Resources 

One  might  ask  why  (given  the  difficuty  of  bringing  new  standards  into  the 
marketplace)  even  attempt  to  abstractly  specify  physical  resources.  For  instance, 
abstracting  operating  system  level  resources  is  tantamount  to  defining  a  stand.ird 
operating  system  (which  has  already  been  done  on  paper,  but  has  not  succeeded  m 
displacing  defacto  standards  such  as  UNIX).  \’v’hy  not  just  adopt  an  e.xisting  Jcldcto 
standard  and  build  on  top  of  it?  This  is  what  is  generally  being  done  today  to  achieve 
some  portability  and  reusability.  Problems  include: 

•  iack  of  formalism  in  specification  of  these  defacto  standards,  resulting  in  less 
than  functionally  equivalent  instantiations  and  inherent  portability  probiems; 

•  knowledge  of  the  underlying  operating  system  layer,  encouraging,  or  at  icast 
enabling,  undisciplined  users  to  bail-out  to  the  operating  system,  violating  the 
layered  functional  information  hiding  structure  to  produce  applications  with 
innerent  portability  and  reuse  problems; 

•  dual  functionality  (i.e..  more  than  one  vvay  to  accomplish  the  same  tiling', 
especially  if  more  than  one  existing  standard  (e.g.,  an  operating  system  .ind  a 
seperate  graphics  kernel)  must  be  combined  to  get  at  the  hardware,  v.'mcii  can 


of  tlie  problem,  and  the  potential  of  our  problem  solving  approach,  at  several  levels. 
Otr.er.  more  specific,  work  to  demenstrate  technical  feasibility  of  functicn.i! 
components  of  this  problem  solving  app.'oach  (some  specifically  cited  in  tins  work  and 
ethers  just  commencing  or  being  encouraged)  are  in  progress  at  Naval  Postgraduate 
•Scliool.  We  hcoe  that  our  work  will  provide  su.fiicent  background  to  '^unufute 
continued  efl'orts  in  an  organized  top  down  manner. 


lead  to  implementations  of  higher  resource  layers  which  are  affected  in  different 
ways,  by  changes  in  the  components  of  the  physical  resource  laser,  ocpcnd.r.c 
on  how  that  particular  implementation  accomplished  something  i  violation  ci 
our  unique  atomic  function  interface  principle  for  layers). 

•  critical  functions  required  but  not  extendible  to  c.visting  defacto  standards  le  g  . 
If  the  environment  must  be  a  trusted  secure  system,  the  \erv  presence  of  an 
existing  operating  system  is  hkels  to  present  realizing  security  which  nvast  be 
designed  in  I'rom  the  beginning  ). 

Physical  resource  functions  to  be  abstracted  should  be  fanuliar.  They  include  t.-.e 
hardware  typically  managed  by  the  operating  system,  graphics  interface  and  daiahase 
.•nanagement  system. 

a.  Abstract  Hardware  Resource  Layer 

The  abstract  hardware  resource  layer  represents  the  hardware  sirtual 
hardware  that  will  host  other  physical  resources  (operating  system  level  resources^ 
The  challenge  a:  this  level  is  to  abstract  needed  hardware  functionality  (which  can  be 
met  with  existing  hardware  technology^  in  a  way  that  allows  extension  (eg. 
parameterizing  the  mterface  to  the  next  high'';  level  in  a  way  that  should  allow  ..ccc^s 
to  future  hardwa.-e.  ’•  )  without  conipionusing  the  integrity  of  the  layer.  Included 
should  be  fanuliar  things  like: 

•  processor's); 

•  primarv  and  secondan.'  memory  stores; 

•  archival  storage  device; 

•  bit  mapped  display; 

•  p.'inter  plotter; 

•  pointing  device; 

•  keyboard; 

•  network  communications  (not  strictly  required  for  IPP.  but  cert  ur.l;.  a 
hinderance  to  extensibility  if  not  available). 


•"The  formal  algebraic  specification  of  abstract  hardware  may  he  i.mpleni-'iiiCvl 
virtual  hardware  hosted  on  some  existing  hardware.  iMm.lar  to  P-^video 
iiiiplerr.cntations)  or  it  may  be  impleinented  as  new  phv  sical  hardware. 

••'Some  crystal  ball  gazing  should  be  beneficial,  but  even  if  the  result  doc--  -'.ot 
allow  the  most  efficient  use  of  all  future  hardware  developments,  rehestme  virtual 
devices  to  new  hardware  should  still  capitalize  on  features  such  as  added  speed  .'la.e 
elfectiv eiy  porting  the  entire  environment  built  above  it.  We  see  tins  sort  cf  tl.iitg  '  ci. 
a  generally  smaller  scalei  in  upwardly  mobile  hardware  .families  vvhere.  ir.rruc':'. 
emulation,  tiie  instruction  set  of  a.n  older  machine,  runs  on  the  newer  :;n.f..i;'.c. 
allo'.v.ng  porting  of  object  code  for  tlte  old  machine  to  the  new  machine. 
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The  abstract  hardware  resource  layer  represents  the  interface  between  real  host 
hardware  and  an  open,  extensible,  portable  and  reusable  environment  cl'  CASE 
resources.  Of  course,  this  nucleus  can  be  broadened  by  addition  of  other  devices  which 
m.:st  then  be  reflected  back  up  through  the  resource  hierarchy  to  (and  down  through 
:ae  hierarchy  from)  the  tool  resources  which  can  use  them. 

!t  IS  cbvicus  that  the  physical  resources  constrain  higher  level  resources, 
ar.d  that  higher  level  resources  drive  the  demand  for  lower  level  resources.  One  should 
not  work,  independently  with  either  set  when  delining  the  functional  resource  hierarchy. 
Instead  one  mast  begin  in  one  place  (either  the  top  or  the  bottom)  and  modei  the 
desired  functionality.  Since  high  level  resources  generally  require  an  aggregate  of  lower 
lesel  functions,  one  should  analyze  the  situation  in  a  combined  top  down  and  bottom 
up  fashion  working  both  ends  (required  high  level  problem  solving  resources  vs. 
asailabie  physical  resources)  towards  a  meeting  point  in  the  middle.  The  goal  is  a 
broad  shallow  hierarchy  with  atomic  functional  resources  at  the  base  which  are  called 
through  the  interface  to  higher  layers  by  resources  providing  compound  lor  aggregate) 
.unctionality  !'*hc  combination  of  atonuc  functions  from  below)  to  the  interface  with 
the  laser  of  even  more  capable  resources  above  them.  Working  in  such  a  fashion  one 
nt.gh:  continue  populating  a  C.ASE  environment  IPP  subset  resource  itierarchy  as 
.'dhows. 

b.  Abitruct  Operating  System  Resource  Layer 

The  name  of  this  layer  is  virtually  self  explanatory.  However,  the  layer  is 
expanded.  bexor.J  more  conxentional  operating  system  functions,  to  handle  d.itabase 
niai'.agcmen:  and  graphics  functions.  The  resource  categories  include: 

•  process  management  (including  multitasking  which  we  consider  critical  to 
product.sity); 

•  men'.orx  rrianagement; 

•  iV.e  'y-tem  managemenii 

•  database  s> stern  management  (the  database  system  is  essential  to  titc 
ii.tcroperability  aspect  of  integration  in  environrnentsi; 

•  .r.pat  odtpat  device  management; 

•  grapnics  kernel. 

As  ^^e;..  rc.  additional  resources  may  be  added  (driven  by  the  balance  of  requirement^ 
frc:.'.  abeve  .igainst  capabilities  fro.m  below).  .As  an  example,  a  security  kemei  niigi'.t 
■'^e  ..dded  ■'.M'ii  hooks  to  security  resources  added  to  the  abstract  hardware  iaxcri  and 
or.  I'om  vccuritx  manager  (.n  the  C.ASE  environment  services  resource  lareri 
',.rp:;t.r.g  ^ecurit;.  requirements  of  the  C.ASE  tool  resource  layer. 
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2.  CASE  Resources 


These  are  the  problem  solving  resources.  They  are  intended  to  interface 
directly,  and  only,  with  the  abstract  operating  system  resource  layer  below,  and  the 
user  above.  There  are  only  two  hierarchical  layers  envisioned  (to  remain  broad  and 
shallow). 

a.  CASE  Environment  Services  Resource  Layer 

Resources  at  this  level  are  the  basis  for  integration  standards  within  the 
C.ASE  tool  resources.  These  resources  arc  the  result  of  the  philosophy  governing  such 
things  as  the  user  interface  design.  Data  interface  standards  are  also  resolved  a:  this 
level,  and  utility  service  resources  (which  have  broad  applicability  among  too!  resources 
and  provide  a  cohesive  functional  aggregate  of  operating  system  level  resources)  would 
also  be  included. 

(1)  User  Interface  Service  Resources.  These  resources  provide  services 
which  directly  support  the  user  interface  guidelines.  Their  presence  is  intended  to 
promote  voluntary  compliance  with  the  user  interface  by  doing  much  of  the  work  in 
advance  and  giving  it  to  tool  resource  developers.  Included  would  be: 

•  event  nianagcr,  the  heart  of  a  responsive  user  friendly  interface,  reports  events 
le.g..  pointing  device  movements,  keyboard  or  pointing  device  key  presses,  to 
the  user  interface  and  ail  other  consistant  C.ASE  too!  resources,  to  winch  thev 
can  respond  by  forking  to  event  handlers,  whereby  tool  level  resources  n.;'. !g:;te 
the  system  reson.-'ca  hierarchy  instead  of  the  user  who  remains  I'ree  to  alter  the 
control  (lew  with  new  events  (whether  an  event  queue  is  polled,  or  events  are 
r.andled  as  priority  interrupts  will  be  key  eificiency  considerations  for  design'; 

•  w’ndo-.v  manager  services  create  and  manipulate  windows  as  objects  uispla;.  ed  to 
convey  information  to  the  user,  classes  of  windows  include  system  windows 
•created  by  the  system  user  interface  tool),  and  tool  windows  icrcated  by  ether 
tool  resources),  either  of  which  may  include  dialog  or  alert  windows; 

•  menu  manager  allows  tool  resources  to  create  and  display  menus  consistent  wltli 
the  user  interface  guidelines,  and  reports  menu  selections  back  to  tiie  tool 
(menus  allow  users  to  chose  options  at  any  time,  menu  options  are  imperatives 
used  analogously  to  conunands  in  more  conventional  systems  'e.g.,  print,  open' 
or  alternatively  they  may  be  selections  (e.g..  font  si/e  type),  user  interlace 
guidelines  should  provide  for  menu  selection  via  pointing  device  or  ..oinmand 
keys,  menus  should  not  be  hierarchical  (avoidance  of  modes'); 

■''Singer  M9S~)  provides  an  in  depth  discussion  of  the  user  interface  philosophv 
and  the  resources  and  guidelines  required  to  achieve  it.  Vde  also  covers  '-ome 
implementation  issues  and  a  discussion  of  the  potential  of  such  a  user  iircrlace  :V. 
signiiicant  productivity  improvement  when  fully  e.vploited  by  advanced  C.\SE  ..'ci 
:  .'•;our..es  si;i.h  as  visual  programmung  tools. 
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•  dialog  manager  used  to  create  and  control  dialog  windows  when  a  tool  resource 
mas:  have  more  information  from  the  user  in  order  to  continue  a  task  (dialogs 
are  modal  if  the  user  must  respond  before  doing  anything  else,  or  modeless  if  the 
User  can  still  do  other  things,  dialogs  may  make  use  of  controls  standardized  by 
the  user  interface  guidelines  and  provided  by  a  controls  manager,  or  text  entries 
■  e.g..  naming  a  file)),  the  dialog  manager  can  also  generate  alert  windows 
I  notes,  i-aunons.  warnings)  when  a  potentially  dangerous  situation  arises 
'  U'uaih  medal ir. 

•  grapn.es  facdiitt's  which  manage  the  dra-.ving  plane  in  terms  of  common 
p.uanicters,  objects,  and  functions  (e.g.,  two  dimensional  coordinate  system  and 
ccr.'.  entions  for  defining  points,  objects,  rectangles,  regions,  bit  images,  bit 
iiiaps.  patterns,  cursors,  graphics  pens,  icons,  transfer  modes,  drawing 
environments  i defining  how  and  where  graphics  operations  will  take  placet, 
etc.  ; 

•  :cx!  facilities  to  perform  basic  text  entn.'  and  editing,  and  handle  difTerent  text 
characteristics  le.g..  te.xt  font.  face.  mode,  size,  leading,  etc.) 

catray.  hihr?,  pp.  d-3"). 

(d)  Data  Model  Manager.  The  data  model  manager  would  provide  for 
anipulat.on  of  the  chosen  environment  process  data  models.  The  technology  exists 
prc'.ide  sophisticated  filters  for  converting  to  and  from  models  supporting  '.anous 
o.e'^ce'  both  internal  and  external  to  this  environment. 

•'i  .Manager.  In  the  interest  of  elnciency  and  responsiseness.  the 

iror.rr.on:  sor.  ice  re'^ources  should  be  resident  in  memory  as  arc  the  operating 
'•eni  rc'carces  and  the  user  .p.terfcce  tool  resource.  L  tiiity  sersice  resources  (iianuled 
:h:  utf.it’.  manager'  and  tool  resources  m  general  would  most  iikeh  be  in  seconuar. 
r.igc  I  ne  first  call  to  such  resources  should  bring  them  into  mem.crx  until  ti'.e;>  are 
n:r  vent  back  b’.  the  user  or.  the  end  of  the  user  session.  It  should  be  a  charactcrist.c 
em. ’.ronm.ent  data  .model  that  objects  created  in  tiie  environment  are  tagged  '.wtii 
1  m.nt.f.  e:  all  cn'.ircnment  resources  used  in  their  creation.  The  utii*t\  manager 
:...a  "e  c-if-ed  b;.  a  resource  recorder  checker  .'unction  'e.g..  of  the  d.iiabavc 
to  '..mate  needed  resources  and  bring  them  into  memcr.  uhen  an.  |'■";ec;  ;s 
.e'-;a  'A'hen  a  reouircd  resource  cannot  ne  found  tlic  user  should  be  tola.  Ma  a 
'  .  ,ne  can  eitner  'uppic  tne  nnsving  resource,  or  proceed  in  some  ctr.er 
n  I  t.l.f.  'csourcCs  ucuiJ  .n.;„de 


•  na.i  O' 

•  .' .r,  ■' :,:rs.  '■.jrious  il.'ers 

:  'e'n.i.  en  • '.r.!  inmeni'  c  a 


mmmt  I'e  defined  to  allow  data  mtcr..h.:nee  a;t;'. 
tne  ccmmunaca'.ons  r.etwo.'k'. 


•  bmiiins  iransformers,  to  allow  glueing  together  parameterized  objects  with 
difTerent  native  contexts  (e.g..  moving  a  language  dependent  code  package  Irom 
a  network  librarx'  into  the  abstract,  language  independent  representation  of  the 
en'.ironment  data  model); 

•  any  of  a  number  of  other  possible  utilities  which  have  broad  apphcability 
among  tool  resources  and  provide  a  cohesive  functional  aggregate  of  system 
ievol  resources  (e.g..  a  parser  or  parsers,  for  the  programming  languages  and 
data  model  supported  by  the  environment,  which  could  be  used  by  a  compdcr. 
debugger,  pretty  printer,  etc.,  or  an  unparser  to  reverse  the  process). 

b.  CASE  Tool  Resource  Layer 

This  layer  consist  of  tools  which  are  integrated  by  their  use  of  the 
underlying  resource  layers  with  adherence  to  user  interface  guidelines,  the  environment 
data  model)  si.  and  the  .manual  and  human  resources  of  the  environment.  It  is  be;.ond 
the  scope  of  this  work  to  complete  any  particular  portion  of  the  abstract  function 
typing  for  an  environment.  .At  this  point  our  purpose  is  just  to  indicate  the  direction 
of  such  an  elTort. 

!h  Endronmeni  User  Interface.  One  might  appropriately  view  the  entire 
C.ASE  environment  resource  hierarchy  as  a  super  operating  system,  with  this  resource 
providing  functicnalit>  similar  to  the  co.mmand  shell  or  command  line  interpreter  of  a 
mere  ccnsentional  operating  system.  Howes  er.  this  resource  is  the  user  .nterface 
guidelines  incarnate,  and  it  exploits  interactive  graphic  user  interface  principles  to 
a^hie'.e  user  friendliness  and  enhance  productivity,  It  is  the  example  for  otlicr  tool 
dc'.  elopers  wlio  uiil  use  the  environment  service  resources  and  user  interface  guidelines 
to  aciiic'.e  ti'.e  ..ontmon  user  interface  aspect  .^or  integration  of  their  too!  into  the 


eii'-  .ronment. 

'!»  Project  .Management  Support.  This  category  of  resources  for  the  IPP 
er.Mronment  maght  include  resources  to  help  an  individual  manage  his  time,  budget,  or 
other  resources.  Objects  generated  here  'e  g.,  schedules  reports!  should  be  designed  to 
;.wil;iate  aggregation  by  the  project  management  support  resources  of  a  Pre  ect 
M.m.acers  en'.ironment  which  is  created  ^y  extending  •b'.  adding  resources  tc  '  ■  t;ve 

!P!’  er. .  .ronment.  IPP  tools  in  this  ..aiegory  magiit  in^iude: 

•  .-''p  eel  'leneau.er, 

•  ".ee  aut  miat.  oi. 


! Aiensians  ■aould  hi\eh.  inciude  sccuritc 
-w^ess  priwiedg-'s  ro  rc^car^es  objects 


resources  i  il'  net  alreads  present'  to 


(3)  System  Generation  and  Management.  This  should  be  a  I'amiliar 
categon'  of  tools  commonly  found  in  programming  support  environments.  These  tools 
must  assist  the  programmer  in  a  verifiable  transformation  of  the  model  of  a  software 
system,  created  in  tlie  Designers  environment,  into  an  executable  model  which  must  be 
validated  against  the  mode!  created  in  the  Analysts  environment.  Some  of  these 
resou-a'cs  should  have  broad  enough  applicability  to  be  useful  in  the  Managers. 
.Inalysis,  Designers  and  Maintainers  environment.  For  example,  the  following  are 
necessary  to  elTectiveiy  manage  ail  of  the  various  models  (i.e..  analysis,  design, 
implementation,  etc.)  within  a  software  project; 

•  documentation  generator, 

•  version  maintainer, 

•  archiver. 

•  backup. 

Other  tods,  in  the  system  generation  and  management  category,  would  include 
programming  language  specific  resources  directly  suppo.'ting  transformation  of  the 
design  mode!  into  the  executable  model.  One  consideration  is  exploitation  of  the 
avahabie  interactive  graphics  of  the  user  interface  (Singer.  198’')  and  the  power  of 
global  models  of  objects  le.g.,  construction  of  objects  by  selecting  templates  and  setting 
controls  or  filling  out  choices  in  dialogs,  manipulation  of  objects  through  their  displaced 
forms,  multiple  simultaneous  views,  animation,  etc.)  with  tools  like  sentax 
kno’.c  ledgeable  editors,  and  interpreting  or  incremental  compiling  debuggers,  to 
imp;  O',  e  productic  ity.  In  other  words,  use  of  visual  progranarrung  techniques,  .\nothcr 
consideration  is  exploration  of  automated  transformation  technology  to  take  advantage 
of  formal  specification  technology  and  calculable  verification  techniques  in  order  to 
fiCal  directly  (with  some  degree  of  automation)  with  the  system  model  generated  in  the 
.Ocsig  ’.ers  -environment.  For  the  IPP  subset  we  would  begin  with  the  more  traditional 
programming  support  environmnt  resources  and  exploit  the  user  interface  for 
produeti'. it>  gains.  Tools  would  includei 

•  synra.v  knowledgeable  edtt‘  r{s). 

1  s 

•  c  impiicr'  .nierpreteris'^. 

•  as'embierisi. 

•  i.e-er  librarian. 

■"Ue  prcl'cr  the  use  of  an  incremental  compiler  for  debugging  smee  it  makes 
.er.fw  ition  easier  titan  if  an  interpreter  is  used  during  development  of  Nource  '.viiun  u  f.l 
;..'cr  be  complied. 

.•'b 


debuggers. 


•  aruilvzers  metrics. 


(4)  System  Integration  and  Testing.  The  IPP  user  must  deal  u-;th 
integration  of  various  system  modules  for  which  he  is  responsible.  In  addition  to 
debugging  and  verification,  he  is  also  concerned  with  validation  of  cohesive  functional 
uiv.ts.  Resources  to  assist  him  in  test  set  generation,  regression  testing,  etc.  are 
required  and  also  form  a  logical  base  for  extension  to  overall  system  integration  and 


testing. 


c.  what  about  the  real  world 


The  foregoing  discussion  presented  an  extremely  high  level  view  of  C.ASE 
resource  functional  abstraction  issues  in  a  very  limited  scope.  Hopefully,  the  benefit  cf 
such  a  discussion  (in  the  context  of  the  current  chaotic  proliferation  of  disjoint 
environments  and  environment  resource  options)  will  be  the  stimulation  cf  well 
directed  top  down  efTorts  to  bring  order  to  the  devlopment  of  C.ASE  environments 
through  such  techniques.  \\'e  will  conclude  with  a  brief  discussion  of  the  major 
cbstacies  to  the  success  of  such  efforts,  directions  for  continuina  this  uork.  and 


rcco.mniendations  for  .MSB. 


.r  V  V.  A 


VI.  CO.NCLUSIONS 


A.  INVITATION  FOR  REVOLUTION 

"Welcome  to  the  CASE  revolution."  proclaimed  the  ebullient  keynote  speaker  at 
a  recent  'symposium  covering  computer-aided  software  engineering  (C.\SE/. 
While  well  meant,  those  words  may  not  have  been  well  ciiosen  for  a  technical 
audience  ever  watchful  of  marketing  hype  and  still  reeling  from  the  past 
re'.oiutions  of  fourth  generation  languages,  relational  data  bases,  structured 
programming  and  real-time  systems.  .  .  .the  thought  of  going  through  yet  another 
resolution  is  less  than  appealing  to  most.  .  .  .appealing  about  CASE.  .  .is  that  its 
tools.  .  .do  not  really  represent  revolution  but  rather  evolution  of  tools  and 
concert':.  .  .ahead;,  embraced  in  the  systems  development  lifecycle.  (Huling.  19S”. 

p. 

iVehsicr's  il966.  p.'37)  defines  revolution  as  ".  .  .  radical  and  complete  change.  .  . 

We  would  agree  that  the  C.ASE  concept  is  evolutionary,  not  revolutionary.  In  this 
thesis  M’c've  acknowledged  the  soft-care  probiem,  and  studied  the  evolution  cf  software 
engineering  towards  solving  it.  We  have  little  doubt  that  C.ASE  environments  are  a 
n.itural  and  needed  stage  in  this  evolution.  Probably  the  most  compelling  evidence  cf 
this  is  the  huge  demand  for.  and  resultant  proliferation  of.  disjoint  C.ASE  tools  and 
fragmentary  environments. 

We've  coalesced,  from  a  variety  of  sources,  spanning  several  \cars.  a  con^encus 
of  fundamental  principles  for  good  environments.  We  ve  reported  on.  the  general  stats 
of  technology  which  fails  to  adhere  to  these  principles,  and  the  technology  and  market 
lacters  vvhich  have  encouraged  such  unprincipled  bottom  up  developments. 

\\'e  ve  reported  on  promising  research,  at  the  Naval  Postgraduate  School, 
involving  formal  specification  of  functional  (physical  and  problem  solving)  resources 
''abstract  I'unction  typing).  We've  proposed  a  top  down  strategy  for  developing 
mtegrated  C.ASE  environments  in  an  open,  extensible,  evolutionary  manner  whwh 
could  achieve  standardization  through  functional  interfaces  allowing  integration  froth 
common  user  interface  and  interoperability)  without  conflict  over  advances  in  hardware 
and  softw.ire  technology,  and  supporting  multtple  processes,  models,  progrr.ntnung 
languages,  etc.,  through  its  extensibility. 

We  vc  discussed  the  major  obstacles  to  such  a  strategy.  The  task  is  Jill'icuit 
because  the  imperatives  include  words  like  agree  and  the  descriptors  arc  werdv  like 


standard.  And.  agreement  on  standards  implies  a  required  shift  in  marketing  strategies, 
especially  for  those  hardware  and  software  houses  whose  symbiotic  relationship  is  the 
basis  for  their  competitive  edge  in  controlling  their  market  share.  Our  strategy 
provides  for  competition  in  hardware  and  software  technologies  directed  not  only 
towards  implementing  standard  functional  resources,  but  also  towards  defining  and 
implementing  nev.-  functional  resource  abstractions  which  will  be  integrated  with  earlier 
resources.  While  this  would  still  allow  for  substantial  competitive  arenas,  they  would 
be  dilferent  than  the  current  arenas.  This  would  be  a  “radical  and  complete  change". 
So,  it  may  be  argued  that  our  strategy  is  an  invitation  for  revolution. 

Revolutions  tend  to  begin  with  a  small  group  of  protagonists  who  must  gather  a 
following  convinced  that  their  cause  is  just  and  that  revolution  is  necessary.  One  goal 
of  this  particular  revolution  is  relief  from  the  current  environment  chaos  and  the  dawn 
of  a  new  age  of  open,  extensible,  integrated  environments  built  from  portable,  reusable 
functional  resources.  Another  goal  is  focusing  competitive  innovation  on  advancing 
the  state  of  technology  without  getting  bogged  down  just  try  ing  to  cope  with  the  chaos 
spawned  along  the  way. 

U'c  believe  the  only  practical  means  of  winning  such  a  revolution  is  to  make  it 
seem  like  evolution.  In  our  discussion  of  standards  enforcement  vs.  encouragement,  we 
.‘avored  encouragement  of  standards  through  good  design,  availahiiity,  and  social  cikuige 
i, realization  that  the  standard  is  a  standard  of  necessity).  Social  change  concerning  this 
issue  is  already  afoot  with  more  and  more  work  focusing  on  abstraction,  rigorous 
for.malism.  user  interface  design  and  object  oriented  software  engineering.  This  is  a 
relatively  slow  process,  but  it  may  be  accelerated  with  a  catalyst  in  the  form  o!' 
availability  oi'  well  designed  resources.  Future  work  should  be  directed  towards  that  end. 

3.  FLTl  RE  WORK 

Functional  analysis  is  probably  the  hardest  part  of  the  task.  We've  discussed  a 
combini.tion  top  down  bottom  up  proccess,  of  balancing  high  level  requi.-emonts 
against  physical  resource  constraints,  in  order  to  arrive  at  an  abstract  fur.^t.on 
'niorar».hy  to  meet  the  requirements.  The  really  di.Ticult  thing  is  to  do  this  witf.out 
letting  perceived  (but  not  actual)  constraints,  derived  from  the  way  things  are  done 
today  I  implementations),  jaundice  the  functional  abstractions.  To  arrive  at  useful 

■’For  e.xampie.  the  chaotic  proliferation  of  programming  languages,  by  tiie  eariv 
19"()  s,  <0  saturated  development  resources  and  hampered  desclopment  of  new 
technology  tnat  desclopment  of  anything  mere  than  rudimentary  programnur.g  support 
locls  ''compilers  assemblers,  linkers  and  leaders)  was  considerably  delayed. 

.^0 


abstractions,  work  should  progress  in  the  context  of  a  real  world  environment  (keeping 
u:  nund  the  ultimate  goal  of  portable  resources).  Detailed  process  and  requi.'-entents 
analysis,  and  understanding,  are  prerequisites  to  the  high  level  balancing  act  required  in 
functional  analysis.  Working  in  the  real  world  (e.g..  the  foundations,  say  an  IPP 
subset,  of  a  C.'XSE  environment  for  an  organization  like  MSB)  demands  practwal 
results  vs.  esoteric  discourse.  Practical  results  are  the  essence  of  catalysts  for  S'-ciu/ 
change- 

Once  a  nainimal  functional  resource  hierarchy  is  available,  abstract  resources 
must  be  formally  specified.  Then,  parallel  efforts  can  be  applied  to  implementation. 
Completed  implementation  of  the  resources  will  constitute  a  prototype  version  of  a 
C.ASE  IPP  environment.  Several  prototypes  should  be  constructed  from  the  same 
formal  specifications,  and  testing  should  be  designed  to  evaluate  achievement  of  the 
principles  for  a  good  C.ASE  environment.  By  repeating  the  process  from  functional 
analysis  through  prototype,  functional  evolution  should  add  C.-XSE  resources  for  d.rect 
support  of  increasing  portions  of  the  software  engineering  lifecycle. 

C.  recommendations  for  MSB 

Depending  cn  the  resources  available  for  such  an  undertaking,  the  make  process 
described  above  could  take  several  years  (not  to  mention  the  time  required  to  win  tlie 
market  revolution  and  see  commercially  available  resources  for  constructing  working 
integrated  C.ASE  environments).  We've  also  said  that  .MSB  lacks  the  rocources  to 
undertake  such  a  project.  Other,  more  practical  solutions  are  of  immediate  concern  to 
MSB. 

1 .  Near  Term 

Given  insufficient  resources  to  make  their  own  C.ASE  environment,  and  the 
inherent  disadvantages  of  the  available  buy  options,  we  decided  to  consider  ^emc  wm: 
of  i'.ybrid,  of  the  available  alternatives,  as  a  potential  means  of  means  of  acquiring 
C.ASE  resources  while  achieving  at  least  some  of  the  advantages  embodied  m  ihe 

■’Encouragement  of  such  development  using  resources  which  represent  Dol) 
sunk  costs  (eg..  Naval  Postgraduate  School  (NPS)  Masters  Candidate'll  and  ..re 
cssentialiy /rce  to  MSB  has  the  potential  to  contribute  to  the  re\  oluticnar;.  ef'ort  m  the 
long  run.  but  is  not  likely  to  olfer  practical  C.ASE  environment  solutions  m  tiic  near 
term.  Bottom  up  NPS  work  on  specific  tool  resources  (not  incorporated  to  date  ur.uer 
a  top  down  C.ASE  environment  development  plan)  like  .AdaMeasure  can  elTe:  .-.mned. 
more  immediate,  practical  benefits  to  .MSB  (while  also  contributing  to  tiicu  evwt.r.g 
di'j.vn:  environment). 


general  principles  for  a  good  environment.  We've  devoted  considerable  thought  to 
hybrid  make  buy  schemes,  and  quite  frankly  there  aren't  miany  good  choices.  •' 
a.  Physical  Resources 

( 1 )  Hardware.  We  believe  that  committment  to  unique  architectures  and 
a  propnctanly  constrained  source  of  software  is  a  nustake  both  now  and  for  the  I'uture. 
Flc\ibi.it>  now.  and  portability  and  reusability  in  the  future,  are  best  ser\ed  by  a 
powerful  general  purpose  hardware  suite.  MSB  has  already  defined  reasonable 
iruninuim  physical  hardware  constraints  i, Missile  Software  Branch,  19S6.  p.  Si.  .At  the 
tune  tl'.ese  constraints  seemed  to  dictate  the  use  of  relatively  high  priced  (S25K  -  S~5K) 
32-bit  professi'.nal  workstations.  Recent  market  releases  of  networkable  ?2-bit  personal 
eopipuu’r  workstations,  rival  the  more  expensive  machines  in  capability  and  arc  driving 
prices  into  a  far  more  alVordable  range  (SSR  -  S25R).  Such  an  alTordable  general 
pu'pose  hardware  base  seems  to  be  a  reasonable  first  step  to  productivity 
improvement,  with  the  capability  to  host  C.ASE  resources  available  today  and  into  the 
I'uture. 

(2)  Operating  System  Resources.  We've  already  discussed  the  problems 
inherent  to  standardizing  on  top  of  an  existing  operating  system.  .A  traditional 
operating  s}  >tem  choice  is  likely  to  be  made  based  on  such  considerations  as: 

•  ^^■hat  do  we  have  cite  most  experience  with  what  do  we  use  now?  (!n  the  ca-e 
o!'  .MSB  the  answer  wouid  likely  be  L'NIX); 

•  l^  our  current  operating  system  adequate? 

•  U'hat  additional  capabilities  (i.e..  graphics,  database)  are  required? 

•  ^^■h:ch  cpe-ating  system  promises  to  support  the  broadest  selection  of  oiT-the- 
si'.eif  tools  M.e..  a  defacto  standard)?' 

.And  sc  cn.  ^^'e  have  little  to  olTcr  here  ether  than  this  common  sense  sort  of  approach 
to  t.w  to  ensure  the  operating  system  will  be  adequate  and  supported  until  sometiting 
Mgnilicur.tiy  better  cemes  along.  Obviously  if  L’NIX  were  kept  as  a  defacto  standard 
cper.iting  system,  a  graphics  capability  would  be  required  (probably  best  to  st.ck  'swh 
■f.'.c  IS'')  GKS  standard).  Since  many  of  the  uicjoint  cff-the-shelf  C.ASF  re^our-c'.  tc  i'e 
'..."•ted  employ  their  own  database  m.magemeni.  a  ciioice  cn  a  database  manaccmeiit 

'•to;'..,  to  augment  the  LNI.X  I’.lc  s\sicm.  nught  either  be  a  non-requirement  or  be 
d...tatcd  S'  the  tool  resources  chosen. 


b.  Problem  Solving  Resources 

So  far  this  near  term  discussion  has  sounded  like  straight  short  term  off-the- 
shelf  buy.  En\  ironment  service  resources  arc  the  level  at  which  we  can  see  practical 
potential  for  compromise  between  the  short  term  off-the-shelf  buy  and  some  portions 
of  the  make  option.  But,  look  ahead  for  a  moment  at  the  disjoint  tools  to  be  bought. 
The  tools  of  the  most  interest  are  likely  to  be  the  new  CASE  tools,  offering  relatively 
complete,  language  independent,  support  to  the  early  software  engineering  phases  of 
structured  analysis,  structured  design,  and  in  some  cases  even  generation  of  source 
code.  I'l'ou  supply  the  compile,  debug  and  test  functions.)  These  tools  in  general  have 
unique  internal  interfaces  for  interoperability.  They  generally  have  primitive, 
unprincipled,  inconsistent,  and  highly  modal  user  interfaces  which  are  also  unique. 
These  tools  generally  do  not  consistently  adhere  to  event  driven  control  vs.  hierarciiical 
modality.  They  generally  support  a  limited  set  of  structured  methodologies.  The  point 
we  re  getting  at  is  that  there  is  little  common  ground  on  which  to  base  environment 
service  resources.  The  internal  interfaces  of  these  various  tools  are  generally  so  deeply 
involved  in  their  design  that  it  is  doubtful  any  monetary  incentive  (especially  something 
MSB  could  offer)  would  entice  a  developer  to  re-engineer  his  tool  to  interact  only 
through  .MSB  standard  data  models  of  objects.  That  leaves  the  user  interface. 

Would  it  be  possible  for  .MSB  to  develop  standard  user  interface  guidelines 
based  on  availability  of  some  suitable  service  package  (say  GEM.  assuming  it  is 
supported  by  the  operating  system  of  choice)  and  then  successfully  get  C.ASE  tool 
developers  ^he  tools  .MSB  really  wants)  to  host  their  tool  on  the  service  package 
with  a  user  interface  conforming  to  the  MSB  guidelines?  Although  probably  less 
di.nicult  than  the  common  data  model  problem,  the  answer  is  still  probably  no.  The 
task  would  not  be  trivial.  *•  and  with  a  market  of  at  most  18  users,  a  proiiibitiv  e 
prwetag  should  be  e.\pected. 

One  other  possibility,  which  falls  somewhere  between  the  long  term  and 
si'.ort  term  off-the-shelf  buy  option,  would  be  to  identify  a  general  purpose  computing 
'•vs'cir.  meeting  the  minimum  hardware  constraints,  for  which  an  operating  s;.  ^tcir. 
suppertmg  a  widely  accepted  (defacto  standard)  well  principled,  event  driven,  user 
fi'ienulv  interactive  graphic  user  interface,  already  e.vists.  While  the  original  .Apple 
Ma..;n;cNh  feii  short  of  the  minimum  hardware  constraints,  the  6S0f0  based  MacintO'-ii 

-'For  example,  few  existing  tools  are  implemented  using  event  driven  program 
uontrol.  '0  m.a^or  restructuring  would  be  required  to  achieve  user  interface  guidelines 
■'..iNeJ  cn  event  driver,  responsivness  and  permissiveness. 


II.  scheduled  for  release  this  summer,  will  come  much  closer.  The  .Macintosh  user 
interface  guidelines  and  service  resources  are  well  principled  and  accepted.  Originally 
targeted  at  a  market  of  unsophisticated  computer  users,  the  Macintosh  still  sulfers 
from  type  casting  as  a  fancy  toy.  However,  it  is  in  fact  a  powerful  system  in  its  own 
right.  Over  a  .Tuilion  users  later,  it  presents  a  lucrative  horizontal  market  to  the 
sol'twarc  developers.  OfT-the-shelf  software  is  plentiful  and  the  user  interface  has 
survived  to  become  a  defacto  standard  for  Macintosh  application  developers,  while  also 
influencing  the  competition.  Among  the  ofl-the-shelf  Macintosh  software  arc. 
sophisticated  syntax  knowledgeable  editor  visual  programnung  incremental  compile 
and  debug  packages,  at  bargain  basement  prices  (thanks  to  the  horizontal  market). 
The  new  .Macintosh  open  architectures  promise  access  to  L'NIX  and  MS-DOS.  The 
point  here  is  that,  at  least  to  the  user  interface  chaos,  there  are  alternatives.  But.  it 
takes  a  committment  on  the  part  of  the  customer,  to  not  accept  deviation  from 
established  user  interface  guidelines.  And.  guideline  adherence  can  be  a  reality  if  you 
give  developers  the  tools  required  to  make  adherence  easier  than  reinventing  the  wheel. 
There  is.  of  course,  always  a  bottom  line.  In  this  particular  discussion  it  goes  like  this. 
.Are  tlte  best  ■..f'unctionally.  i.e..  disregard  the  kluge  user  interface)  off-the-shelf  C.ASE 
tools  available  for  Macintosh?  What  about  .Ada  support?  The  answers  are  generally 
not yei.  Can  MSB  alone  get  a  developer  to  port  his  product  to  Macintosh  (adhering  to 
the  user  interface)?  Probably  not.  but  the  incentive  ought  to  be  greater  due  to  a 
potentially  larger  market. 

Sadly,  the  bottom  line  of  the  whole  near  term  issue  would  seem  to  be.  il' its 
a  matter  of  survival,  join  the  competition  and  buy  up  the  disjoint  tools  of  your  chcisc. 

2.  The  Future 

We  are  firmly  convinced  that  the  future  of  C.ASE  environment  devclcpment 
lies  along  the  path  we've  proposed  for  functional  abstractior^  and  formal  spccilication 
of  phv'ical  and  problem  solving  resources.  Key  to  this  effort  are  standardization  on 
user  interfaces,  and  interoperability  based  on  manipulation  of  global  ch;octs. 
Con-'i'-tency  checking,  validation,  verification,  and  testing  must  also  be  fgunded  on  fne 
objcots  themselves  and  their  interrelationships.  Efforts  like  C.AIS  within  the'DoD  ^oent 
to  'n.ivo  a  start  on  this  path  in  an  extremely  limited  and  language  specif.c  way.  and  'un^ 
rigorou>  formalism.  But,  they  are  a  start,  and  enjoy  direct  support  from  a  much,  higi'.cr 
level  within  not  only  the  DoD  bureaucracy,  but  (due  to  clout)  within  the  indtistrs  a'-  a 
wliole.  If  MSB  wants  better  choices  in  tne  future,  we  recommend  they  aggrcvM'. eh 
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lobby  the  DoD  infrastructure  to  expand  ^vork  like  CAIS  in  the  direction  ueAc 
proposed. 
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